search for: mcsectioncoff

...; MCStreamer -> MCObjectWriter has > proven somewhat problematic, mostly due to my lack of understanding. > I guess MCSectionXXX was meant to provide communication between them. > Should the same be true of MCSymbol, and their data counterparts? I'm enclosing my patch for reforming MCSectionCOFF to match the implementation strategy of the other two MCSection classes. You may find it useful as a starting point. It seems to be complete and correct, and worked for what I tried with it, but I didn't find time to test it fully (e.g., by bootstrapping clang under Cygwin). Cheers, -Peter- -...

On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with...

Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with...

On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > Thanks! Funny, I was just preparing a patch to submit for my changes to > MCSectionCOFF. My changes look to be fairly independent of yours, my change > was to deal with COMDAT's. I had dealt with the characteristics flags in the > object writer, but I like this. If you don't mind I would like to merge my > changes into this patch and submit it. I was just pondering ho...

For those that are interested, I have attached the latest version of my Win32 COFF support patch. There is no new functionality, I just fixed some compiler errors due to recent changes in the MC library. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100527/23598d23/attachment.html>

...are interested, I have attached the latest version of my > Win32 COFF support patch. There is no new functionality, I just fixed some > compiler errors due to recent changes in the MC library. One more review comment: + bool isVirtualSection(const MCSection &Section) const { +// const MCSectionCOFF &SE = static_cast<const MCSectionCOFF&>(Section); +// return SE.getType() == MCSectionCOFF::SHT_NOBITS; + + return false; // not sure how to interpret this right now + } Please get rid of the commented-out code and make the comment use FIXME so it's clear there's an issu...

On Wed, Jun 23, 2010 at 12:22 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > I'm now going to make the stub patches that Daniel requested. Added llvm/Support/COFF.h and merged in COFF constants from llvm/MC/MCSectionCOFF.h. Zeroth patch is done. http://github.com/Bigcheese/llvm-mirror/commit/2d88aa08a072bb5f8d687b67d1476f23d37a87d4 A svn-style patch against svn HEAD is also attached. - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: ms-coff-patch-0.svn.patch T...

I just finished the initial split up of WinCOFF.h into llvm/Support/COFF.h and lib/MC/WinCOFFObjectWriter.cpp. This includes almost the minimum changes required to split them up. WinCOFFObjectWriter now needs some refactoring to make things more consistent and less verbose. There also seem to be quite a few memory leaks that need to be resolved.

...ently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > >> > > I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect? You'd have to ask Daniel about this. I don't recall if this is a sho...

...a/lib/Target/X86/X86AsmBackend.cpp >> +++ b/lib/Target/X86/X86AsmBackend.cpp >> @@ -14,6 +14,7 @@ >>  #include "llvm/MC/MCAssembler.h" >>  #include "llvm/MC/MCExpr.h" >>  #include "llvm/MC/MCObjectWriter.h" >> +#include "llvm/MC/MCSectionCOFF.h" >>  #include "llvm/MC/MCSectionELF.h" >>  #include "llvm/MC/MCSectionMachO.h" >>  #include "llvm/MC/MachObjectWriter.h" >> @@ -212,6 +213,24 @@ public: >>      : ELFX86AsmBackend(T) {} >>  }; >> >> +class WindowsX...

...e assembler backend >> should maintain a DenseMap from MCSymbol* to whatever data you need to >> associate with a symbol.  This is equivalent to embedding per-symbol stuff >> in the MCSymbol itself.  MCSection should be subclassed and you should put >> COFF specific stuff in MCSectionCOFF. > > I think this is an important detail I was missing. I can already see how > this will help with COMDAT sections. Is there any reason for the difference > between symbol and section in this respect? > > You'd have to ask Daniel about this.  I don't recall if this is a s...

...t at gmail.com> wrote: > > > On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: >> >> Thanks! Funny, I was just preparing a patch to submit for my changes to >> MCSectionCOFF. My changes look to be fairly independent of yours, my change >> was to deal with COMDAT's. I had dealt with the characteristics flags in the >> object writer, but I like this. If you don't mind I would like to merge my >> changes into this patch and submit it. I was just...

Hi guys, I have attached my patch to support generating win32 COFF object files. I would have posted earlier, but my system drive crashed and I had to rebuild my system; Luckily, my source code was on a secondary drive. I think this would be a good beginning for ongoing support of the COFF object file format and was hoping for some feedback as to whether it was commit worthy or what was needed to

...ently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > I had a problem with MCStreamer::EmitCommonSymbol & MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this meant to put those symbols into the .bss segment. This required me to get a hold of the TLOF from the streamer. I now realize this is wrong after re-reading the d...

...> #define report_fatal_error_dbg(x) __debugbreak () Generally it's prohibited to use target/compiler-specific defines outside of libSystem. > struct MCWin32CoffObjectWriter : > MCObjectWriter, > coff::file Any reason for such inheritance? > MCSectionCOFF const & Section = dynamic_cast <MCSectionCOFF const &> (SectionData.getSection ()); LLVM normally compiles w/o RTTI, so this won't work > CoffSection->Header.Characteristics |= > coff::IMAGE_SCN_CNT_CO...

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This

...ementation of the assembler backend > should maintain a DenseMap from MCSymbol* to whatever data you need to > associate with a symbol. This is equivalent to embedding per-symbol stuff > in the MCSymbol itself. MCSection should be subclassed and you should put > COFF specific stuff in MCSectionCOFF. > > I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect? As others have pointed out, this is one of the many horrors of C :) > > Another reason w...

...ackend.cpp >>> +++ b/lib/Target/X86/X86AsmBackend.cpp >>> @@ -14,6 +14,7 @@ >>>  #include "llvm/MC/MCAssembler.h" >>>  #include "llvm/MC/MCExpr.h" >>>  #include "llvm/MC/MCObjectWriter.h" >>> +#include "llvm/MC/MCSectionCOFF.h" >>>  #include "llvm/MC/MCSectionELF.h" >>>  #include "llvm/MC/MCSectionMachO.h" >>>  #include "llvm/MC/MachObjectWriter.h" >>> @@ -212,6 +213,24 @@ public: >>>      : ELFX86AsmBackend(T) {} >>>  }; >>&...

...re.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...

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one