search for: emitcommonsymbol

I compile these two lines in llc @tst1 = internal global [4 x i8] zeroinitializer; @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; @tst1 is emited via MCStreamer::EmitCommonSymbol while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, is this the expected behavior or should I fix it? -------------- next part -------------- An HTML attachm...

...t figured out how to change the way globals are emitted. The AsmPrinter::EmitGlobalVariable function in the llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp file is not virtual; if I try to override it, I get a "multiple definitions" error. To emit the global, it just calls the OutputStreamer.EmitCommonSymbol method. Again, this has become a problem because I don't want the default output for global symbols. If I can't override this method, how can I change the way that my target outputs globals variables? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:...

...; > On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: > > > I compile these two lines in llc > > > > @tst1 = internal global [4 x i8] zeroinitializer; > > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; > > > > @tst1 is emited via MCStreamer::EmitCommonSymbol > > while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes > > > > from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, > > > > is this the expected behavior or should I fix it? > &...

...he way > globals are emitted. > > The AsmPrinter::EmitGlobalVariable function in the > llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp file is not virtual; if I try to > override it, I get a "multiple definitions" error. To emit the global, it > just calls the OutputStreamer.EmitCommonSymbol method. Again, this has > become a problem because I don't want the default output for global symbols. > If I can't override this method, how can I change the way that my target > outputs globals variables? Ryan, On which version are you working? I can see, since r93858; Author...

...10:01 PM, Nathan Jeffords wrote: >> >> > I compile these two lines in llc >> > >> > @tst1 = internal global [4 x i8] zeroinitializer; >> > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; >> > >> > @tst1 is emited via MCStreamer::EmitCommonSymbol >> > while the other is emited via MCStreamer::EmitLabel followed by >> MCStreamer::EmitBytes >> > >> > from what I can tell, only symbols with common linkage should me emitted >> by MCStreamer::EmitCommonSymbol, >> > >> > is this the expecte...

...he same as the intentions behind its design. It seemed to be that having these calls with the restrictions on when they would be allowed would simplify an object file writers job sifting though the incoming data and organizing into what will become the output file. 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 description of the '.comm' directive a few times....

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

...er how llvm-dlltool would fit in the entire picture of mingw > support. I don't think dlltool is the last missing piece. What do you need > to do other than that to fully support mingw using LLVM toolchain? Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm within the EmitCommonSymbol function and a single patch for mingw-w64 itself to pre-populate it's .ctors and .dtors list, so llvm-dlltool is infact the only missing part really. This gives us a fully working clang based mingw-w64 C compiler. C++ and exception handling is a different story. libc++ is somewhat working wit...

...What is the preferred method in MC to jump back to a prior section > already defined? (Or is this not supported?) SetSection in the MCStreamer if you really want to change the current section, but maybe all that you need is to setSection in the Symbol? Similar to what is done in MCELFStreamer::EmitCommonSymbol if the binding is local. > 2. It looks like the "correct" way to write out these blobs in ELF  is > to add a new virtual interface to MCElfStreamer to emit the ARM > specific chunks. > I'd prefer to add a new subclass of MCELFStreamer to do this, but, it > looks like t...

...e picture of mingw >>> support. I don't think dlltool is the last missing piece. What do you need >>> to do other than that to fully support mingw using LLVM toolchain? >> >> Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm >> within the EmitCommonSymbol function and a single patch for mingw-w64 >> itself to pre-populate it's .ctors and .dtors list, so llvm-dlltool is >> infact the only missing part really. >> > > Also you need to make a change to LLD/COFF to accept GNU command > arguments, right? (Looks like you alre...

...signed ByteAlignment, bool External); > + > // MCStreamer interface > > virtual void EmitLabel(MCSymbol *Symbol); > @@ -52,18 +79,18 @@ public: > virtual void EndCOFFSymbolDef(); > virtual void EmitELFSize(MCSymbol *Symbol, const MCExpr *Value); > virtual void EmitCommonSymbol(MCSymbol *Symbol, uint64_t Size, > - unsigned ByteAlignment); > + unsigned ByteAlignment); > virtual void EmitLocalCommonSymbol(MCSymbol *Symbol, uint64_t Size); > virtual void EmitZerofill(const MCSection *Section, MCSymbol *S...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

On Wed, May 5, 2010 at 1:22 PM, Nathan Jeffords <blunted2night at gmail.com> wrote: > 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 description of the '.comm' dir...

...support. I don't think dlltool is the last missing piece. What do you need >>>>> to do other than that to fully support mingw using LLVM toolchain? >>>> >>>> Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm >>>> within the EmitCommonSymbol function and a single patch for mingw-w64 >>>> itself to pre-populate it's .ctors and .dtors list, so llvm-dlltool is >>>> infact the only missing part really. >>>> >>> >>> Also you need to make a change to LLD/COFF to accept GNU command &gt...

Hi everyone, while looking at the ARMAsmPrinter::EmitStartofAsm function, I realized that what looks like singular assembler directives (.eabi_attribute) are in fact shorthand that needs to go in to the .ARM.attributes section in the ELF file. 1. What is the preferred method in MC to jump back to a prior section already defined? (Or is this not supported?) 2. It looks like the

On Mon, Mar 26, 2012 at 01:22:01PM -0400, Villmow, Micah wrote: > Tom, > Two things. One is missing tests. I have some I could send you, but they are mainly OpenCL based for the AMDIL backend, not for the R600. > I've started working on the tests, and I've pushed a few up to my llvm repo. I can add the AMDIL tests too if you want to send them. I think they will be helpful.

...ol is the last missing piece. What do you need >>>>>>> to do other than that to fully support mingw using LLVM toolchain? >>>>>> >>>>>> Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use >>>>>> -aligncomm within the EmitCommonSymbol function and a single patch for >>>>>> mingw-w64 itself to pre-populate it's .ctors and .dtors list, so >>>>>> llvm-dlltool is infact the only missing part really. >>>>>> >>>>> >>>>> Also you need to make a chan...

...at do you need >>>>>>>>> to do other than that to fully support mingw using LLVM toolchain? >>>>>>>> >>>>>>>> Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use >>>>>>>> -aligncomm within the EmitCommonSymbol function and a single patch for >>>>>>>> mingw-w64 itself to pre-populate it's .ctors and .dtors list, so >>>>>>>> llvm-dlltool is infact the only missing part really. >>>>>>>> >>>>>>> >>>>&...

...ltool would fit in the entire picture of mingw > support. I don't think dlltool is the last missing piece. What do you need > to do other than that to fully support mingw using LLVM toolchain? > > Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm > within the EmitCommonSymbol function and a single patch for mingw-w64 > itself to pre-populate it's .ctors and .dtors list, so llvm-dlltool is > infact the only missing part really. > > > Also you need to make a change to LLD/COFF to accept GNU command > arguments, right? (Looks like you already have tha...

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. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer