similar to: [LLVMdev] Directly generating binary file

On Mon, 27 Feb 2006, Vladimir Prus wrote: > I'm looking for a way to make the the "llc" tool (or any other tool), > directly produce a binary file for some target. ok > The TargetMachine class has a method 'addPassesToEmitMachineCode', that's > suitable for that, but that method also requires an instance of > MachineCodeEmitter. Actually, you probably

Chris Lattner wrote: >> The TargetMachine class has a method 'addPassesToEmitMachineCode', that's >> suitable for that, but that method also requires an instance of >> MachineCodeEmitter. > > Actually, you probably want to plug into the addPassesToEmitFile API, when > FileType is set to ObjectFile. X86TargetMachine::addPassesToEmitFile > demonstrates

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?

> 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. This could > be

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter,

On Mon, Mar 16, 2009 at 3:26 AM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray < > aaronngray.lists at googlemail.com> wrote: > >> I like the idea of a generic MachineCodeWriter, although I prefer the >>> name 'ObjectFileWriter'... >>> >> >> Thats much more descriptive of

I like the idea of a generic MachineCodeWriter, although I prefer the name 'ObjectFileWriter'... I think we need to take a hard look at which bits of the Writer/Emitter infrastructure are needed for what tasks (Object File Emittion, JIT, etc.) and make sure that our abstractions are flexible enough... As it stands at the moment, the Writer and Emitter classes could definately be merged

> 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. This could > be

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

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

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

>I like the idea of a generic MachineCodeWriter, although I prefer the >name 'ObjectFileWriter'... Thats much more descriptive of the functionality. >I think we need to take a hard look at which bits of the >Writer/Emitter infrastructure are needed for what tasks (Object File >Emittion, JIT, etc.) and make sure that our abstractions are flexible >enough... I would

First, I'm not sure if deleting the ExecutionEngine is all I need to clean-up... so I started with a minimal test just to check int main( int argc, char **argv ){ while( true ){ Module *M = new Module("M"); Function *F = cast<Function>(M->getOrInsertFunction("F", Type::Int32Ty, (Type*)0)); BasicBlock *BB = new

A couple notes on this: 1. We also need to be able to *read* .o files for linking. Right now we just assume that any symbol not found in a bytcode file is implemented in some native library and will be resolved at runtime. This isn't the greatest assumption. To resolve native binary symbols we need to be able to read native .a, .so, and .o files to ensure the symbols are