search for: elfwriters

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

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

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

+llvmdev On Fri, Nov 12, 2010 at 7:57 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 10, 2010, at 9:57 AM, Jason Kim wrote: > >> Refactoring the x86 dependent code from ELFObjectWriter class has >> repercussions among several (conflicting) axes of consideration, >> >> 1. namespace pollution - minimize pollution of the llvm:  namespace >> 2.

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:

On Wed, 15 Jun 2005, Reid Spencer wrote: > So, here's the plan: > > 1. No reading interface. To have a system agnostic interface for reading > a dynamic library, use System/DynamicLibrary. No plans for reading a > native object file for any kind of examination purpose (at least, not > for a long while). Sounds good. > 2. We will support .so/.dll and .o/.obj file output.

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

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

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

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

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

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

Hello All, Some people thought about a n LLVM wiki. Is there some alreadly? I wish it would be linked from LLVM.org site. Here are a few questions which I would like to be answered (preferably on a Wiki, to possibly participate): assuming that LLVM (latest from CVS) was configure-d with ./configure '--ENABLE-TARGETS=HOST-ONLY' '--WITH-GNU-LD' My main (currently platonic - ie

Owen Anderson wrote: > There's nothing particularly stopping you from having your > installation package include copies of gas and ld, I disagree. gas and ld are not available on Windoze, except via MinGW. Yes I can make or tell my customers to install MinGW, but if MinGW is installed, then I don't need LLVM. (More about this further ahead) > You're welcome to think