search for: objectwriter

...CTargetOptions) -> (*MCAsmBackendCtorFn)(..., MCTargetOptions) -> <MCAsmBackend subclass constructor wanting options>(..., MCTargetOptions) adds MCTargetOptions to the MCAsmBackend subclass state or the bits needed <MCAsmBackend subclass wanting options>::createObjectWriter(...) -> create<foo>ObjectWriter(..., added information) -> <foo>ObjectWriter::<foo>ObjectWriter(..., added information) sets added state based on constructor args, in my case the ABI, IsILP32 <foo>ObjectWriter::GetRelocType(...) use state to guide which...

...o read everything as MachO. FYI, I've been working wth Daniel to try and pull all the Mach-O specific things out of llvm-mc and lib/MC and put them into object file classes. Once those patches are merged it should be a small matter of programming to get COFF support for llvm-mc, given that the ObjectWriter and Streamer stuff is already written.

Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct object gen...

...p; "Invalid size!"); case 1: OW->Write8 (uint8_t (it.getValue())); break; case 2: OW->Write16(uint16_t(it.getValue())); break; case 4: OW->Write32(uint32_t(it.getValue())); break; case 8: OW->Write64(uint64_t(it.getValue())); break; } } Note: ObjectWriter has a set of endian correcting routines as use above. The output routines like the snippet above would be in lib/MC/MCAssembler.cpp There is an MCInstFragment, but it doesn't seem to be used. All text and data seem to go through MCDataFragment. The offset/size container would be filled at th...

...; wrote: > FYI, I've been working wth Daniel to try and pull all the Mach-O > specific things out of llvm-mc and lib/MC and put them into object file > classes. Once those patches are merged it should be a small matter of > programming to get COFF support for llvm-mc, given that the ObjectWriter > and Streamer stuff is already written. How would this work? Aren't there object type specific directives in assembly files? I know some people are working on native linkers for LLVM. It would be interesting to see an architecture for handling object files that could be shared between lib...

...the new ABI. For Mips N32, code and state in MCELFObjectTargetWriter seems to take care of mapping the relocation values and the ELF e_flags bit EF_MIPS_ABI_ON32 is set. I'm trying to implement the AArch64 ILP32 ELF ABI.Ideally, I'd like to be able to create a modified version of AArch64ELFObjectWriter so that its GerRelocType method can choose which relocation encoding to use based upon what was specified on the command line. Should I make up a new OSABI enum value? Do some kind of manipulation of the Triple environment field to set it based upon the value of "-mabi="? ARM64 ELF  Refer...

I need to create a subclass that derives from MCELFStreamer. We use MCELFStreamer for direct object generation and need to override a virtual method in the base class MCStreamer::EmitGPRel32Value(). I have been having trouble creating the subclass due to #include issues. I can't seem to get it right at the lib/target/<my target>/MCTargetDesc level. My first thought is always that I am

...xecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer - a PassManager for scheduling of an AsmPrinter (MCLowering) using the streamer - MCJITStreamer - owns and creates : - a MCAssember - a MCJITObjectWriter - a mem_raw_ostream - knows : - the MCJIT : to give it to the object writer (for mapping) - the MemoryManager : to give it to the object writer (for memory claiming) - MCJITObjectWriter - knows : - the MCJIT : for mapping GlobalVariable <-> native address - the Memory...

On Fri, May 28, 2010 at 4:28 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > Any objections for not accepting the patch into LLVM? If none, I'll > > apply it after the weekend. > > There should minimally be a bare-bones test to make sure that basic > COFF writer functionality doesn't crash.  Besides that, I don't see > any issues. I was looking

...___ From: Jim Grosbach [grosbach at apple.com] Sent: Tuesday, November 15, 2011 8:57 AM To: Carter, Jack Cc: llvmdev at cs.uiuc.edu List; Daniel Dunbar Subject: Re: [LLVMdev] MCELFStreamer subclassing Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct object gene...

...case 1: OW->Write8 (uint8_t (it.getValue())); break; > case 2: OW->Write16(uint16_t(it.getValue())); break; > case 4: OW->Write32(uint32_t(it.getValue())); break; > case 8: OW->Write64(uint64_t(it.getValue())); break; > } > } > > Note: ObjectWriter has a set of endian correcting routines as use above. > > The output routines like the snippet above would be in lib/MC/MCAssembler.cpp > > There is an MCInstFragment, but it doesn't seem to be used. All text and data > seem to go through MCDataFragment. > > The offset/size...

...case 1: OW->Write8 (uint8_t (it.getValue())); break; > case 2: OW->Write16(uint16_t(it.getValue())); break; > case 4: OW->Write32(uint32_t(it.getValue())); break; > case 8: OW->Write64(uint64_t(it.getValue())); break; > } > } > > Note: ObjectWriter has a set of endian correcting routines as use above. > > The output routines like the snippet above would be in lib/MC/MCAssembler.cpp > > There is an MCInstFragment, but it doesn't seem to be used. All text and data > seem to go through MCDataFragment. > > The offset/...

...(uint8_t (it.getValue())); break; >> case 2: OW->Write16(uint16_t(it.getValue())); break; >> case 4: OW->Write32(uint32_t(it.getValue())); break; >> case 8: OW->Write64(uint64_t(it.getValue())); break; >> } >> } >> >> Note: ObjectWriter has a set of endian correcting routines as use above. >> >> The output routines like the snippet above would be in lib/MC/MCAssembler.cpp >> >> There is an MCInstFragment, but it doesn't seem to be used. All text and data >> seem to go through MCDataFragment. &gt...

...That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. For your specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPR...

...That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. For your specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPR...

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high level hammer to do ballpeen > work..... But when in Rome.... :-)

...That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. > > For your specific problem, I suspect what needs to happen is something like: > > 1) In MCELFStreamer(...

...YI, I've been working wth Daniel to try and pull all the Mach-O > > specific things out of llvm-mc and lib/MC and put them into object file > > classes. Once those patches are merged it should be a small matter of > > programming to get COFF support for llvm-mc, given that the ObjectWriter > > and Streamer stuff is already written. > > How would this work? Aren't there object type specific directives in > assembly files? > Once the assembler is no longer directly dependent on MachO, all sections would be the object file specific versions. At that point it would...

...> a+b), to do that some modifications have been made : - The addPassesToEmitMC method has been added to TargetMachine class. It fills the MCContext pointer so we can build the MCJITStreamer. - The Finish method of MCAssembler have a new optional argument "Writer" to allow a custom MCJITObjectWriter to be used. Can you give us some feedbacks on the general idea and on this 2 particular hooks ? Currently MCJIT has one unittest and the binary size is quite big (~110MB in debug...) because before using the MC framework we need to call "InitializeAllTargets()" and friends (same as llc...

...rious ones) a custom fix-up, that still wouldn't require subclassing. For example, look at how ARM handles upper and lower. Take a look at ARM/MCTargetDesc/ARMMCExpr.h ARM/ARMAsmPrinter.cpp ARM/MCTargetDesc/ARMFixupKinds.h ARM/MCTargetDesc/ARMMCCodeEmitter.cpp ARM/MCTargetDesc/ARMMachObjectWriter.cpp - Daniel > > -Jim > >> One of the issues I hit initially with llvm is that in terms of relocation and fixups there was an assumption of universal fixups/relocation types. That was really Utopian. These need to be all down in the Target regions and not in the base classes. Even...