similar to: [LLVMdev] MachO writer test cases

I doubt anyone is using it, as it is not complete. On Jun 1, 2009, at 9:12 AM, Aaron Gray wrote: > Is anyone using the MachO Writer ? > > If so do you have any test cases as I am moving it over to use the > prototype direct object emission code and I need test cases to > verify it working correctly. > > Many thanks in advance, > > Aaron > >

Nate, Right, okay. I was also planning on looking at what the assembly output generates and "emulating" its output. So I should be able to use the 'test/CodeGen/PowerPC' tests once I have augmented the MachO Writer PowerPC output. Does this seem like the right and sensible approach ? Aaron ----- Original Message ----- From: Nate Begeman To: LLVM Developers Mailing

On Jun 1, 2009, at 12:18 PM, Aaron Gray wrote: > Nate, > > Right, okay. I was also planning on looking at what the assembly > output generates and "emulating" its output. Sure. I was using the source for 'as' and 'ld' as my guide when I was working on it. > > So I should be able to use the 'test/CodeGen/PowerPC' tests once I > have

>> 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 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 the functionality. > Sorry, I disagree actually the MachineCodeEmitter or the 'MachineCodeWritter' does not do any file

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? There are 3 classes which

>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

Hi, I am working on the direct object module emission, and am wondering if anyone is successfully using the MachO backend. Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090515/b8b96813/attachment.html>

> 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

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo or getELFWriterInfo, and returns a

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

On May 15, 2009, at 6:25 AM, Aaron Gray wrote: > Hi, > > I am working on the direct object module emission, and am wondering > if anyone is successfully using the MachO backend. > Nope, it's just as broken (if not more so) than the ELF writer, don't worry about breaking it. If you wanted to #if 0 it out, that would also be fine with me. -Chris -------------- next

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

> 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

> 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

Hi! I think llvm-mc did amazing work and I'm stunned ;). - So I start reading source-code and making notes. To my question: At which state is the disassembly for PEcoff or ELF? I read the blog (http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html): """ The MC components have been designed to be object file independent (e.g. work for MachO, ELF, PE-COFF etc) but only have

On Dec 6, 2011, at 7:43 PM, Eli Friedman wrote: > On Tue, Dec 6, 2011 at 7:29 PM, Carter, Jack <jcarter at mips.com> wrote: >> Is there an official llvm method of creating and submitting test cases that >> don't affect .s assembly files? >> >> When we check in changes that can affect the .s output we submit .ll files >> with the internalized semicolon

Is there an official llvm method of creating and submitting test cases that don't affect .s assembly files? When we check in changes that can affect the .s output we submit .ll files with the internalized semicolon instructions on how to check the output .s file. For direct output we currently add to our own test suites that check for correctness. Does the llvm community depend on the