[LLD] Do not assume /guard:cf always set together with /guard:ehcont

[pengfei]

Summary

MS link accepts *.obj with ehcont bit set only. LLD should match this
behavoir too.

[rnk]

lld/COFF/Writer.cpp

1735–1739

Please update this comment to avoid discussing EH continuations.

My understanding is that if you compile with /guard:ehcont- and link with /guard:ehcont, then attempts to catch exceptions in the unprotected object files will crash the program with control flow violations, but correct me if I am wrong. There is no attempt to conservatively handle objects that catch exceptions but not /guard:ehcont, they must all be recompiled with EH continuations, correct?

[pengfei]

Update comments.

lld/COFF/Writer.cpp

1735–1739

Good catch!

This patch is to fix a problem as a side effect of D150645. User expected both cf and ehcont bits are set in the obj files and link with both. However, we only have ehcont present due to the bug.
I don't know if this would be a problem in reality, but separating cf and ehcont in lld matches with MS link. So I think it's still good to go with this.

[rnk]

lgtm

[pengfei]

Thanks @rnk !

lld/COFF/InputFiles.h

public:
   // like stack guard, safeseh, /guard:cf, or other things.
   uint32_t feat00Flags = 0;
 
   // True if this object file is compatible with SEH.  COFF-specific and
   // x86-only. COFF spec 5.10.1. The .sxdata section.
   bool hasSafeSEH() { return feat00Flags & 0x1; }
 
   // True if this file was compiled with /guard:cf.
-  bool hasGuardCF() { return feat00Flags & 0x4800; }
+  bool hasGuardCF() { return feat00Flags & 0x800; }
+
+  // True if this file was compiled with /guard:ehcont.
+  bool hasGuardEHCont() { return feat00Flags & 0x4000; }
 
   // Pointer to the PDB module descriptor builder. Various debug info records
   // will reference object files by "module index", which is here. Things like
   // source files and section contributions are also recorded here. Will be null
   // if we are not producing a PDB.
   llvm::pdb::DbiModuleDescriptorBuilder *moduleDBI = nullptr;
 
   const coff_section *addrsigSec = nullptr;

lld/COFF/Writer.cpp

void Writer::createGuardCFTables() {
   Configuration *config = &ctx.config;
 
   SymbolRVASet addressTakenSyms;
   SymbolRVASet giatsRVASet;
   std::vector<Symbol *> giatsSymbols;
   SymbolRVASet longJmpTargets;
   SymbolRVASet ehContTargets;
   for (ObjFile *file : ctx.objFileInstances) {
     // If the object was compiled with /guard:cf, the address taken symbols
-    // are in .gfids$y sections, the longjmp targets are in .gljmp$y sections,
-    // and ehcont targets are in .gehcont$y sections. If the object was not
-    // compiled with /guard:cf, we assume there were no setjmp and ehcont
-    // targets, and that all code symbols with relocations are possibly
-    // address-taken.
+    // are in .gfids$y sections, and the longjmp targets are in .gljmp$y
+    // sections. If the object was not compiled with /guard:cf, we assume there
+    // were no setjmp targets, and that all code symbols with relocations are
+    // possibly address-taken.
     if (file->hasGuardCF()) {
       markSymbolsForRVATable(file, file->getGuardFidChunks(), addressTakenSyms);
       markSymbolsForRVATable(file, file->getGuardIATChunks(), giatsRVASet);
       getSymbolsFromSections(file, file->getGuardIATChunks(), giatsSymbols);
       markSymbolsForRVATable(file, file->getGuardLJmpChunks(), longJmpTargets);
-      markSymbolsForRVATable(file, file->getGuardEHContChunks(), ehContTargets);
     } else {
       markSymbolsWithRelocations(file, addressTakenSyms);
     }
+    // If the object was compiled with /guard:ehcont, the ehcont targets are in
+    // .gehcont$y sections.
+    if (file->hasGuardEHCont())
+      markSymbolsForRVATable(file, file->getGuardEHContChunks(), ehContTargets);
   }
 
   // Mark the image entry as address-taken.
   if (config->entry)
     maybeAddAddressTakenFunction(addressTakenSyms, config->entry);
 
   // Mark exported symbols in executable sections as address-taken.
   for (Export &e : config->exports)

lld/test/COFF/guard-ehcont.s

 # REQUIRES: x86
 # RUN: llvm-mc -triple x86_64-windows-msvc %s -filetype=obj -o %t.obj
 # RUN: lld-link %t.obj -guard:cf -guard:ehcont -out:%t.exe -entry:main
 # RUN: llvm-readobj --file-headers --coff-load-config %t.exe | FileCheck %s
 
 # CHECK: ImageBase: 0x140000000
 # CHECK: LoadConfig [
 # CHECK:   SEHandlerTable: 0x0
 # CHECK:   SEHandlerCount: 0
 # CHECK:   GuardCFCheckFunction: 0x0
 # CHECK:   GuardCFCheckDispatch: 0x0
 # CHECK:   GuardCFFunctionTable: 0x14000{{.*}}
-# CHECK:   GuardCFFunctionCount: 1
+# CHECK:   GuardCFFunctionCount: 4
 # CHECK:   GuardFlags [ (0x400500)
 # CHECK:     CF_FUNCTION_TABLE_PRESENT (0x400)
 # CHECK:     CF_INSTRUMENTED (0x100)
 # CHECK:     EH_CONTINUATION_TABLE_PRESENT (0x400000)
 # CHECK:   ]
 # CHECK:   GuardAddressTakenIatEntryTable: 0x0
 # CHECK:   GuardAddressTakenIatEntryCount: 0
 # CHECK:   GuardEHContinuationTable: 0x14000{{.*}}
_load_config_used:
         .fill 12, 1, 0
         .quad __guard_iat_table
         .quad __guard_iat_count
         .quad __guard_longjmp_table
         .quad __guard_longjmp_count
         .fill 72, 1, 0
         .quad __guard_eh_cont_table
         .quad __guard_eh_cont_count
-        .fill 32, 1, 0
+        .fill 32, 1, 0