search for: machocodeemitter

...ipate in object file emission: 1. MachOWriter - a MachineFunctionPass, with a donothing runOnMachineFunction. doInitialization and doFinalization are used to emit the object file header and finalize the various object file segments, respectively. The MachOWriter is responsible for creation of MachOCodeEmitter, via it's getMachineCodeEmitter function. 2. MachOCodeEmitter - a MachineCodeEmitter. Friend class of MachOWriter (friend class == broken encapsulation!?) startFunction allocates storage in the text section for the current function. finishFunction emits constant-pools, jumptables; transfo...

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

...calling TargetMachine::addPassesToEmitFile, then adding my own CodeEmitter/CodeWriter (exactly like llc does). I have to say I always hated code emitter interface but at least it worked for me. Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own code emitter and it's always MachOCodeEmitter which of course I don't need. Is there a new way to create non-JIT object code in LLVM 2.7? -- Best Regards Peter Shugalev

...then adding my own CodeEmitter/CodeWriter (exactly like llc does). I >> have to say I always hated code emitter interface but at least it worked >> for me. >> >> Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own >> code emitter and it's always MachOCodeEmitter which of course I don't need. >> >> Is there a new way to create non-JIT object code in LLVM 2.7? > > Nope, sorry. This will hopefully be coming in 2.8. Mainline llvm can already do macho quite robustly for x86-32 and x86-64. > > -Chris > What exactly is expecte...

...3. X86CodeEmitter > - a MachineFunctionPass, NOT a MachineCodeEmitter (Could the naming > change perhaps?) Yes, it uses a MachineCodeEmitter in its internals (MCE) and as a constructor argument. > This class receives (during construction) a reference to a > MachineCodeEmitter (e.g. MachOCodeEmitter, which in turn stores a > reference to a MachOWritter). > > The runOnMachineFunction for the X86CodeEmitter does: > - call MachOCodeEmitter::startFunction > - for each basicblock in function: > - call MachOCodeEmitter::StartMachineBasicBlock > - for each instruction in basi...

...esToEmitFile, > then adding my own CodeEmitter/CodeWriter (exactly like llc does). I > have to say I always hated code emitter interface but at least it worked > for me. > > Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own > code emitter and it's always MachOCodeEmitter which of course I don't need. > > Is there a new way to create non-JIT object code in LLVM 2.7? Nope, sorry. This will hopefully be coming in 2.8. Mainline llvm can already do macho quite robustly for x86-32 and x86-64. -Chris

On Mar 27, 2010, at 3:41 AM, Peter Shugalev wrote: >>> Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own >>> code emitter and it's always MachOCodeEmitter which of course I don't need. >>> >>> Is there a new way to create non-JIT object code in LLVM 2.7? >> >> Nope, sorry. This will hopefully be coming in 2.8. Mainline llvm can already do macho quite robustly for x86-32 and x86-64. >> >> -Chris >&...

Chris Lattner wrote: > On Mar 27, 2010, at 3:41 AM, Peter Shugalev wrote: > >>>> Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own >>>> code emitter and it's always MachOCodeEmitter which of course I don't need. >>>> >>>> Is there a new way to create non-JIT object code in LLVM 2.7? >>> Nope, sorry. This will hopefully be coming in 2.8. Mainline llvm can already do macho quite robustly for x86-32 and x86-64. >>> >>> -Chr...