ELF / COFF Summary

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.

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

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

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

The interface that I'm suggesting would abstract away the differences.
The user of ELFWriter would have to declare whether they want 32-bit or
64-bit, but that's about it. I'll probably use the GELF interface to
implement ELFWriter to make it easier to work with either elf32 or
elf64.

Reid.