[llvm-dev] lld: ELF/COFF main() interface

Rafael EspĂ­ndola via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 20 07:30:27 PST 2016


Sorry for being late on this thread.

I just wanted to say I am strongly on Rui's side on this one.

There current design is for lld *not* not be a library and I think
that is important. That has saved us a tremendous amount of work for
doing library like code and a lot of design for library interfaces.
The comparison of old and new ELF code is night and day as far as
productivity and performance are concerned. Designing right now would
be premature because it is not clear what commonalities there will be
on how to refactor them.

For example, both MCJIT and lld apply relocations, but there are
tremendously different options on how to factor this

* Have MC produce position dependent code and MCJIT would be a bit
more like other jits and not need relocations.
* Move relocation processing to LLVM somewhere and have lld and MCJIT use it.
* Have MC produce shared objects directly, saving MCJIT the
complication of using relocatable objects.
* Have MCJIT use lld as trivial library that implements "ld foo.o -o
foo.so -shared".

The situation is even less clear for the other parts we are missing in
llvm: objcopy, readelf, etc.

We have to discuss and prototype these before we can make a decision.
Committing now would be premature design and stall the progress on one
thing we are sure we need: A high quality, bsd  license linker. Lets
get that implemented. While that MCJIT will move along and we will be
in a position to productively discuss what can be shared and at what
cost (complexity and performance).

Last but not least, anything that is not needed in two different areas
should remain application code. The only point of paying the
complexity of writing a library is if it is used.

Cheers,
Rafael


More information about the llvm-dev mailing list