[LLVMdev] Win32 COFF Support

[Chris Lattner]

On May 5, 2010, at 6:44 PM, Nathan Jeffords wrote:
> ...
> Thanks, applied in r103150!  llvm-mc -filetype=obj probably needs a similar patch.
> 
> 
> cool!, I will make that change and submit it too. 

Thanks!

> Also, w.r.t. section handling stuff, there is this fixme in the asmprinter:
> 
>     } else if (const char *LinkOnce = MAI->getLinkOnceDirective()) {
>       // .globl _foo
>       OutStreamer.EmitSymbolAttribute(GVSym, MCSA_Global);
>       // FIXME: linkonce should be a section attribute, handled by COFF Section
>       // assignment.
>       // http://sourceware.org/binutils/docs-2.20/as/Linkonce.html#Linkonce
>       // .linkonce discard
>       // FIXME: It would be nice to use .linkonce samesize for non-common
>       // globals.
>       OutStreamer.EmitRawText(StringRef(LinkOnce));
>     } else {
> 
> Basically, it seems like the MCSectionCOFF implementation should get the linkonce bit.  I'm not an expert on COFF, but I think that's the right place for it.  ".linkonce" will also have to be added as a new MCStreamer api, which would set the bit.
> 
> 
> linkonce is one option for COFF COMDAT sections. I think that this call should not exist at all, instead, when the AsmPrinter asks the TLOF what section to use for the global, TLOF should create a new unique section with the bit set already.

Yeah, I completely agree.  That's what I was thinking when I wrote that comment :).  However, doing it that way would break .s emission, which is "bad" :)

Also, to implement a COFF assembler, we'd need to support the .linkonce directive.  To me, it seems most straight-forward to just support .linkonce as a MCStreamer callback.

> One thing that I don't understand is why common symbols do not get sections assigned to them. I ended up assigning them to the '.bss' section in my streamer (which I now know was wrong) but it still seems like they should be part of some section. At least in COFF, they will be handled as a COMDAT just like symbols with the linkonce linkage type.
> 
> I guess this all goes back to the assembly language view of things. I think I have enough information to handle these things correctly now.

I'm not sure (all I know about COFF is what's on this page: http://www.nondot.org/sabre/os/articles/ExecutableFileFormats/) but you can find out by making a .s file, running it through a coff assembler (like gas) and seeing what bits it produces.  When working on the macho assembler, we found it very very useful to produce bitwise identical output to the system assembler, allowing us to just diff the .o files.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/2872c911/attachment.html>