[LLVMdev] ELF / COFF Summary

[Reid Spencer]

On Fri, 2005-06-17 at 00:22 -0500, Chris Lattner wrote:
> On Wed, 15 Jun 2005, Reid Spencer wrote:
> > 4. If Chris will expound on his design for the way to implement
> > TargetMachine::addPassesToEmitObject, that sounds like a good way to go.
> > However, doesn't this mean the ELF/COFF interfaces should be at the same
> > level? I'm looking at the X86/X86CodeEmitter.cpp file and the various
> > methods for emitting instructions/blocks/addresses/etc. Shouldn't the
> > ELF/COFF interfaces be somewhat similar?
> 
> I don't think it should be templated at all.  Basically we want an 
> interface that is like the AsmPrint interface described here:
> include/llvm/CodeGen/AsmPrinter.h
> 
> Targets use this interface by deriving from AsmWriter, 

Wait, AsmPrinter or AsmWriter. This confused me on your last email on
this subject to. AsmWriter is in VMCore. I really don't think this is
what you're talking about .. or ARE you?  If you meant AsmPrinter, then
I understand.

> then filling in the 
> various fields in the derived ctor.  You can see examples of this in the 
> X86 and PPC backend.

Okay, I'll mimic AsmPrinter (which is what I assume you meant).
> 
> 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.

Okay.

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

Okay, I'll put this stuff in lib/CodeGen (makes sense) instead of having
a separate directory for it. I was following the pattern that file
formats like Bytecode have their own directory.

Regarding what it does and its interface, please see:

http://www.mr511.de/software/english.html (software)
http://docs.sun.com/app/docs/doc/816-5172/6mbb7btp9?a=view (Man pages)

This isn't our ELFWriter software, its the actual libelf software from
which ELFWriter will be constructed. We agreed previously to include it
in LLVM because you didn't want to force the user/developer to obtain it
separately and configure LLVM with that. What I've done is simply make
libelf configurable by LLVM and build in the LLVM build tree. So, the
correct name is ELF, I believe and I'll put it in lib/CodeGen/ELF.

On top of that there will be an include/llvm/CodeGen/ELFWriter.h that
will specify the LLVM interface to ELF file writing and a
lib/CodeGen/ELFWriter.cpp file to implement that interface. Those files
haven't been created yet as they were the subject of my original message
about plans for this interface.

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050616/d67b132c/attachment.sig>