[ms] Add @feat.00 magic symbol to COFF object files from AsmParser

[epastor]

Summary

Allows assembly files targeting 32-bit Windows to be linked with /safeseh.

For example, Boost Context distributes GNU-syntax assembly files for its primitives, but if assembled with clang, neither link.exe nor lld-link can link them with /safeseh.

Code ported from X86AsmPrinter.cpp, which already emitted this into X86 assembly... but we need it here to inject it into assembly that doesn't already have the symbol defined. (See http://llvm-cs.pcc.me.uk/lib/Target/X86/X86AsmPrinter.cpp#599)

[epastor]

• Fix comment.

[epastor]

• Restrict @feat.00 symbol creation to the initial text segment.

[craig.topper]

Test case?

[epastor]

• Fix tests
• Add @feat.00 testing to basic-coff{,-64}.s

[merge_guards_bot]

Build result: fail - 60328 tests passed, 1 failed and 732 were skipped.

failed: LLVM.MC/COFF/feat00.s

Log files: console-log.txt, CMakeCache.txt

[craig.topper]

Is it possible for someone to write something in their hand written assembly related to SEH that would make this behavior incorrect?

[epastor]

• Fix missed change

[merge_guards_bot]

Build result: pass - 60329 tests passed, 0 failed and 732 were skipped.

Log files: console-log.txt, CMakeCache.txt

[epastor]

In D70757#1762286, @craig.topper wrote:

Is it possible for someone to write something in their hand written assembly related to SEH that would make this behavior incorrect?

Not yet, no - or maybe just not yet without extreme contortions. This is only incorrect if an SEH handler is registered, but not registered for safeseh processing (by listing its symbol index in the .sxdata section).

To register an SEH handler, one normally uses the .seh_handler directive - which LLVM doesn't currently implement for 32-bit configurations. (In MASM, one would use the FRAME parameter to PROC.) This would be somewhere between odd and impossible to do by hand.

If at some later date we implement .seh_handler for 32-bit configurations, or (as I'm working on) support PROC when building via a new llvm-ml driver, this would become incorrect; we'd need to set this bit iff the user specified safeseh to the assembler, as ml.exe does with the /safeseh command-line switch.

[rnk]

I don't think we should do this implicitly. Assembler should be a low level representation of what the programmer wants in the symbol table. That includes @feat.00. There is existing nasm documentation covering this. Basically, this is something the programmer has to know if they want to target windows:
https://nasm.us/doc/nasmdoc7.html

There are a couple of other @feat.00 bits that the compiler could set. Wouldn't this create problems then with clang -save-temps, where we parse the .s output and assemble it? I'd expect the default @feat.00 and the explicit one in the .s file to conflict.

[rnk]

Another way to look at it would be, if you round-tripped assembly through llvm-mc repeatedly, would you accumulate @feat.00 symbol definitions in the textual assembly?

[epastor]

In D70757#1762394, @rnk wrote:

There is existing nasm documentation covering this. Basically, this is something the programmer has to know if they want to target windows:
https://nasm.us/doc/nasmdoc7.html

Thanks, Reid! So to clarify: our standards for this are to match nasm for the current interface?

As for roundtripping... I'll have to check, but it seems likely to be a problem. If necessary, I'll withdraw this and leave it to be managed by whatever interface ends up used to emulate MASM. (ml.exe and ml64.exe both emit @feat.00 implicitly into their symbol tables, with ml.exe setting the LSB if /safeseh is passed.)

[epastor]

In D70757#1762394, @rnk wrote:

I don't think we should do this implicitly. Assembler should be a low level representation of what the programmer wants in the symbol table. That includes @feat.00. There is existing nasm documentation covering this. Basically, this is something the programmer has to know if they want to target windows:
https://nasm.us/doc/nasmdoc7.html

Hang on. NASM documents the following:

Former can be easily achieved with any NASM version by adding following line to source code:

$@feat.00 equ 1

As of version 2.03 NASM adds this absolute symbol automatically. If it's not already present to be precise.

Would it be acceptable to match NASM, adding the symbol automatically unless it's already defined? Or do we want to stick closer to the ideal that we emit no symbols other than those explicitly given?

[epastor]

• Switch to adding @feat.00 as a final symbol, and only if not defined.

[merge_guards_bot]

Build result: pass - 60329 tests passed, 0 failed and 732 were skipped.

Log files: console-log.txt, CMakeCache.txt

[rnk]

In D70757#1762398, @epastor wrote:

Thanks, Reid! So to clarify: our standards for this are to match nasm for the current interface?

No, LLVM MC is modeled after GNU binutils as. It's not strictly compatible, since we had to extend the .section directive for COFF to express certain extensions, but binutils is usually the first place we look for prior art. Nasm is just a good second place to look for how other assemblers handle common issues.

As for roundtripping... I'll have to check, but it seems likely to be a problem. If necessary, I'll withdraw this and leave it to be managed by whatever interface ends up used to emulate MASM. (ml.exe and ml64.exe both emit @feat.00 implicitly into their symbol tables, with ml.exe setting the LSB if /safeseh is passed.)

In the spirit of following gnu as when possible, I think it would be better to make this conditional on some kind of masm mode setting.

llvm/lib/MC/MCParser/AsmParser.cpp

 #include "llvm/ADT/None.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Twine.h"
+#include "llvm/BinaryFormat/COFF.h"
 #include "llvm/BinaryFormat/Dwarf.h"
 #include "llvm/DebugInfo/CodeView/SymbolRecord.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/MCCodeView.h"
 #include "llvm/MC/MCContext.h"
 #include "llvm/MC/MCDirectives.h"
 #include "llvm/MC/MCDwarf.h"
 #include "llvm/MC/MCExpr.h"
getContext().setGenDwarfFileNumber(getStreamer().EmitDwarfFileDirective(
         /*CUID=*/0, getContext().getCompilationDir(), RootFile.Name,
         RootFile.Checksum, RootFile.Source));
   }
   return true;
 }
 
 bool AsmParser::Run(bool NoInitialTextSection, bool NoFinalize) {
   // Create the initial section, if requested.
-  if (!NoInitialTextSection)
+  if (!NoInitialTextSection) {
     Out.InitSections(false);
 
+    if (Ctx.getObjectFileInfo()->getObjectFileType() ==
+        MCObjectFileInfo::IsCOFF) {
+      // Emit an absolute @feat.00 symbol.  This appears to be some kind of
+      // compiler features bitfield read by link.exe.
+      MCSymbol *Feat00Sym = getContext().getOrCreateSymbol("@feat.00");
+      getStreamer().BeginCOFFSymbolDef(Feat00Sym);
+      getStreamer().EmitCOFFSymbolStorageClass(COFF::IMAGE_SYM_CLASS_STATIC);
+      getStreamer().EmitCOFFSymbolType(COFF::IMAGE_SYM_DTYPE_NULL);
+      getStreamer().EndCOFFSymbolDef();
+      int64_t Feat00Flags = 0;
+
+      if (getContext().getObjectFileInfo()->getTargetTriple().getArch() ==
+          Triple::x86) {
+        // According to the PE-COFF spec, the LSB of this value marks the object
+        // for "registered SEH".  This means that all SEH handler entry points
+        // must be registered in .sxdata.  Use of any unregistered handlers will
+        // cause the process to terminate immediately.  LLVM does not know how
+        // to register any SEH handlers, so its object files should be safe.
+        Feat00Flags |= 1;
+      }
+
+      getStreamer().EmitSymbolAttribute(Feat00Sym, MCSA_Global);
+      getStreamer().EmitAssignment(
+          Feat00Sym, MCConstantExpr::create(Feat00Flags, getContext()));
+    }
+  }
+
   // Prime the lexer.
   Lex();
 
   HadError = false;
   AsmCond StartingCondState = TheCondState;
   SmallVector<AsmRewrite, 4> AsmStrRewrites;
 
   // If we are generating dwarf for assembly source files save the initial text