...> Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a similar > patch. > >cool!, I will make that change and submit it too.> ... > Yes probably, I don't know what the .def and .scl directives "do" :) > >I think I can figure out the right thing to do here.> 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. 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. Thanks for the feedback. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/297528de/attachment.html>
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>
On Wed, May 5, 2010 at 9:38 PM, Chris Lattner <clattner at apple.com> wrote:> 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! > >After looking into this, I have found that AsmParser is hard coded to use MachO sections which causes my code to segfault, reworking this code to use TargetLoweringObjectFile or some equivalent is a larger change than I am comfortable with at the moment. On the other hand, llc, clang, and (according to Aaron) llvm-gcc all work with my COFF backend, so I will continue to work on it using one of those to test it.> - Nathan-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/f40371e6/attachment.html>