search for: tlof

...Optional<CodeModel::Model> CM, CodeGenOpt::Level OL, bool JIT) : LLVMTargetMachine(T, computeDataLayout(TT), TT, CPU, FS, Options, getEffectiveRelocModel(RM), getEffectiveCodeModel(CM), OL), TLOF(make_unique<TargetLoweringObjectFileELF>()), Subtarget(TT, CPU, FS, *this) { initAsmInfo(); } LanaiTargetMachine::LanaiTargetMachine(const Target &T, const Triple &TT, StringRef Cpu, StringRef FeatureString,...

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

...## @tst2 > .ascii "\000\001\002\003" > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in 'lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. It looks to me that you should have an Emit method for the .scl, .def, .type, .endef directives. One callback each. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

...## @tst2 > .ascii "\000\001\002\003" > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in ' lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. We also need to sort out COFF TLOF, and get rid of the directive stuff. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/b624435f/attachment.html>

On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute

...gt; .ascii "\000\001\002\003" >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in 'lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. >> >> We also need to sort out COFF TLOF, and get rid of the directive stuff. > > It looks to me that you should have an Emit method for the .scl, .def, .type, .endef directives. One callback each. > > -Chris > > I've had included a EmitCOFFSymbolDef in MCStreamer to replace the EmitRawText that was handling this...

...---------- so far I am unsuccessful in modifying llvm to work around the problem, I have tried all the variations below, and always end up with either assembler or linker errors void AsmPrinter::EmitReference(const MCSymbol *Sym, unsigned Encoding) const { const TargetLoweringObjectFile &TLOF = getObjFileLowering(); const MCExpr *Exp = TLOF.getExprForDwarfReference(Sym, Mang, MMI, Encoding, OutStreamer); const MCSectionMachO * SecCur = dyn_cast<MCSectionMachO> (getCurrentSection()); const MCSectionMachO * SecRef = dyn_cast<MCSectionMachO>(&Sym- >g...

...gt; .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. > > -Chris > I've had included a EmitCOFFSymbolDef in MCStreamer to replace the EmitRawText that was handling t...

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

...g 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. I am not sure why an uninitialized global variable was being emitted using this, that seems wrong since global variables in different compilation units with the same name w...

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

...subclassed. This implies that it can't have virtual methods. > TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic. TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho. > Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer. Right, that is the actual implementation of t...

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). Would it make sense to delegate the implementation to a specialized object from current the object file format? I am tempted to make it the MCAsmInfo

...gt; .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. > There is already a MCStreamer::EmitZerofill() is seems to be MachO specific ? 'MCStreamer::EmitCOFFStabs()' ?...

...2\003" >>> >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream >> methods, the latter to deal with dllexports in ' >> lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. >> >> We also need to sort out COFF TLOF, and get rid of the directive stuff. >> >> >> It looks to me that you should have an Emit method for the .scl, .def, >> .type, .endef directives. One callback each. >> >> -Chris >> > > I've had included a EmitCOFFSymbolDef in MCStreamer to replac...

...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' directive a few times.  I am not > sure why an uninitialized global variable was being emitted using this, that > seems wrong since global variables in different compilation units with...

...rgetMachine(T, computeDataLayout(TT, CPU, Options, isLittle), >> TT, >> CPU, FS, Options, getEffectiveRelocModel(TT, RM), >> getEffectiveCodeModel(CM), OL), >> TargetABI(computeTargetABI(TT, CPU, Options)), >> TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) { >> ... >> } >> It does not create a separate Subtarget, and its getSubtargetImpl() tries to >> get the value >> from SubtargetMap. >> >> Is there any downside to keep BPFTargetMachine as is? Or it is wort...

...t can't have virtual methods. > > > TargetLoweringObjectFile looks to perform a similar function as > MCAsmInfo, though this doesn't look to be responsible for directing the > AsmPrinter, its only responsibility appears to be providing section > assignment logic. > > TLOF is designed to be specific to the object file, but ideally not target > specific. This means we should have TLOFMacho but not TLOFX86Macho. > > In the context I am looking at, it would be specific to the object file. I was just pointing out that as it stands, it appears to only be responsi...

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

...ould 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 description of the '.comm' directive a few times. I am not sure why an uninitialized global variable was being emitted using this, that seems wrong since global variables in different compilation units with the same name w...