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 .so/.dll
* Chris: Just .so/.dll and .o
* Jeff/Chris/Alexander: emitting both .o and .so/.dll eliminates
the need for a native assembler or gas which is important for
Win32 because it doesn't distribute with an assembler. This is
also important for compiler writers as it reduces dependencies
on other software packages and makes the compilation process
faster.
3. Should the level of abstraction (LOA) to object code interface be
something along the lines of "add function" or "add global
var"?
* Alexander: yes
* Chris: no, make it more abstract. create a template class whose
parameter is an object file writer that the various targets can
use to implement a new TargetMachine::addPassesToEmitObject
4. Do we want to expose arbitrary construction of ELF/COFF?
* Reid: no
* Alexander: no
* Chris: no, keep ELF/COFF implementations separate
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).
2. We will support .so/.dll and .o/.obj file output. There will be no
support for .exe or .a output.
3. The interface will deal with ELF and COFF output separately with
separate interfaces for them.
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?
5. I have libELF building under LLVM. Its in lib/ObjCode/ELF (new).
Should I commit it?
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/20050615/29bb594c/attachment.sig>
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. There will be no > support for .exe or .a output.Sounds good.> 3. The interface will deal with ELF and COFF output separately with > separate interfaces for them.Sounds good.> 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, then filling in the various fields in the derived ctor. You can see examples of this in the X86 and PPC backend. 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.> 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/
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>
> 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.The only catch here is elf32 and elf64 use different data structures. Other than than, I agree. I suspect we are going to need two base implementations to handle that difference. Andrew