search for: elfcodeemitt

> 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 "FIXME" and an abort at the beginning of the ELFCodeEmitter::startFunction. This is why I used MachO to 'grok' the concept. > > >> 3. X86CodeEmit...

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

We generating object files, not using the JIT so I don't know if those fixes applies in our case. As far as using PIC goes, the ELFCodeEmitter has asserts to tell you that PIC isn't currently supported. Will have to get the 2.7 update and try it out. Thanks. -----Original Message----- From: Howell, Nathan [mailto:nhowell at ebay.com] Sent: Thursday, June 17, 2010 3:45 PM To: Eli Friedman; Smith, Tim Cc: llvmdev at cs.uiuc.edu Su...

I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for

...ere to in order to get something to work ? Simon. $ llc -filetype=dynlib -f -o=helloworld.so helloworld.bc llc: target 'X86' does not support generation of this file type! $ llc -filetype=obj -f -mcpu=i386 -march=x86 -o=helloworld.o helloworld.bc llc: ELFWriter.cpp:81: virtual void llvm::ELFCodeEmitter::addRelocation(const llvm::MachineRelocation&): Assertion `0 && "relo not handled yet!"' failed. llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x8ac5736] llc((anonymous namespace)::SignalHandler(int)+0xed)[0x8ac59cb] [0xffffe420] /lib/tls/libc.so.6(abort+0x1d2)[0xb7...

So far, for X86 identical ELF relocation flags show up in include/llvm/Support/ELF.h and lib/Target/X86/X86ELFWriterInfo.h Not to mention, there are two different files named ELF.h ./lib/CodeGen/ELF.h ./include/llvm/Support/ELF.h I'd think the latter should be renamed MCELFSupport.h Thanks! -jason

...two different files named ELF.h I would say that ELF.h should be the canonical one. > ./lib/CodeGen/ELF.h > ./include/llvm/Support/ELF.h > > I'd think the latter should be renamed MCELFSupport.h The first one should probably be removed. It is included from JITDebugRegisterer.cpp ELFCodeEmitter.cpp ELFWriter.cpp We might be able to remove the last two files today. Any missing information in the first can probably be inlined while the MCJIT is implemented. I will take a look at what is using this. > Thanks! > -jason Cheers, Rafael

...ements of the object file format. > > Alternatively, you could side step all of this and write your own .o file > writer that doesn't use the MachineCodeEmitter interfaces at all. If this > is easiest, go for it. So far this looks the simplest approach. Especially sincelooking at ELFCodeEmitter, I see quite a bunch of unimplemented methods. > Note that *some* assembler format is useful for debugging, writting > regression tests, etc. Sure, I plan to have some format that will be output by disassembler, but don't plan to ever read that format ;-) - Volodya

On Apr 12, 2006, at 10:23 PM, Simon Burton wrote: > > Is it possible to get llvm to generate native machine code > without using gcc and friends ? Do I use lli ? llc. llc --help lists all the options. it compiles llvm bytecode files. > > I'd like to directly create executable code that i can > stick in memory somewhere and jump into (call). > > (I'm looking

Is it possible to get llvm to generate native machine code without using gcc and friends ? Do I use lli ? I'd like to directly create executable code that i can stick in memory somewhere and jump into (call). (I'm looking to use llvm in a BSD licensed project). Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

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

Hi! I'm looking for a way to make the the "llc" tool (or any other tool), directly produce a binary file for some target. The TargetMachine class has a method 'addPassesToEmitMachineCode', that's suitable for that, but that method also requires an instance of MachineCodeEmitter. The existing MachineCodeEmitter derived classes are either debug-only (writing to

> 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

> 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

...gt; which passes the MachineFunction to the MachineCodeEmitter. The > MachineCodeEmitter calls back to the ObjectCodeEmitter in order to > look up sections/segments, add globals to an unresolved globals list > etc. > No look at the ELFWriter which inherits from MachineFunctionPass and ELFCodeEmitter which inherits from the MachineCodeEmitter. We need to override the behaviour of the MachineCodeEmitter creating the ObjectCodeEmitter which writes to the appropriate section in ELFWriter::ELFSection.SectionData. > I'm not too happy about the broken encapsulation here. I'd prefer t...

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