search for: elfwrit

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

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 :- > > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > > To get rid of these easily turned out to be a semicomp...

Hi, Have you guys considered libelf [1] for implementing ELFWriter? [1] http://people.freebsd.org/~jkoshy/download/libelf/article.html Regards, -Mahadevan.

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

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

...sting >> createELFObjectWriter, and without namespace pollution to llvm, >> creates a linkage dependency failure). >> I will reply to this thread with a patch as soon as I finish this variant. >> >> There are several attachments: >> >> small: >> small-elfwriter-cpp (application/octet-stream) 2K >> small-elfwriter-rename-record (application/octet-stream) 2K >> >> tryA >>  arm-mc-elf-s07-elfwriter-tryA-combined.patch (text/x-patch) 43K - >> this is the combined patch - In order to make it more clear, I broke >> up the s...

I'm trying to build LLVM on OPENBSD current with today's svn (feb 23), and it fails to build with the following errors: llvm[2]: Compiling ELFWriter.cpp for Release build In file included from ELFWriter.cpp:51: /root/llvm/include/llvm/Target/TargetLoweringObjectFile.h:345: error: virtual outside class declaration /root/llvm/include/llvm/Target/TargetLoweringObjectFile.h:345: error: non-member function 'unsigned int llvm::getPersonalityE...

...f the file format are common across targets and what the variations are caused by. > 5. I have libELF building under LLVM. Its in lib/ObjCode/ELF (new). > Should I commit it? What does it do, how is it structured? Can you email out the interface for feedback? I would suggest lib/CodeGen/ELFWriter or something similar, since it is effectively a part of the target-independent code generator. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/

We've had various discussions about ELF/COFF support in LLVM. Here's a summary and action plan. 1. Do we need a "reading" interface? * Reid: No * Alexander: Yes * Chris: No * Jeff: We already have this in lib/System (DynamicLibrary.h) 2. Do we support just .so/.exe or all object formats? * Reid: Just .so/.dll .exe and .o * Alexander: Just

...LF (which is not used anywhere, > BTW). > Ideally, I'd like to create my own MachineCodeEmitter derived class, load it > into llc with the -load option, and then have new option for 'llc' that > will use MachineCodeEmitter, not AssemblyWriter, to generate the file. Yup, the ELFWriter.cpp file should be a reasonable template to base your work on, but note that it is not complete at this point. > The reason I'm trying to do this is that the target does not have an > assembler, and does not need it, and so designing an assembler syntax just > for the sake of code...

Hi all, I have interest in some ideas, some I've seen in the Open project pages (copied straight from there) and some are by my own, they are: 1) Implement MachOWriter and ELFWriter to allow LLVM-based compilers to bypass an external assembler. This may include the idea of an assembler for inline assembly 2) Write a disassembler for machine code that would use TableGen to output MachineInstrs for transformations, optimizations, etc. I read two interesting papers on this so...

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

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

On 22 November 2010 20:52, Jason Kim <jasonwkim at google.com> wrote: > 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 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....

> In the case of the ELF writer, we want a similar structure. Anything that > can be simple exposed as data should be (e.g. whether the target is 32- or > 64-bit), anything more complex should be exposed as virtual methods that > are overloaded. The ELF spec makes it very clear what parts of the file > format are common across targets and what the variations are caused by.

...ode and use the MachineCodeEmitter class to do this. > ObjectCodeEmitter, is responsible for emission of object 'files' into > a memory buffer. This includes handling of all object headers, > management of sections/segments, symbol and string tables and It writes to sections in ELFWriter::ELFSection.SectionData which are std::vector<unsigned char>. > relocations. The ObjectCodeEmitter should delegate all actual 'data > emission' to the MachineCodeEmitter. No it will have to parallel the MachineCodeEmitter as a generic alternative. > ObjectCodeEmitter is...

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

...red object comparable? i'm also suggessting adapting the simple JIT examples (or providing new ones) to possibly emit c file or elf shared object? how to delete the code in a JIT-ed in-memory module? i cannot figure out how to canonically get the host target (ie the TargetMachine argument to ElfWriter) when configured with '--enable-targets=host-only' - shouldn't we have only one TargetMachine in that case? Mayvbe a static TargetMachine* TargetMachine::getHostTarget() function could help? Regards, and thanks for reading. -- Basile STARYNKEVITCH http://starynkevitch.net/...

...is NOT "multi-year projects". I agree with what Holger Schurig said: "[...] So it is actually possible to do this with limited resources (the FPC developer community isn't that large). It just has to be done." Also, Nick Lewycky said that there is ALREADY an unfinished ELFWriter and MachOWriter in lib/Codegen/ ! Owen Anderson wrote: > You, as the developer, install/build binutils in MinGW. > Then you pull the executables out and stick them in the > package that you give your clients. Thus the clients > don't need MinGW. Interesting suggestion, how c...