[LLVMdev] Is lld the linker we need for our project ?

[Kuba Ober]

Rodolphe,

Your work in this direction is much appreciated as I will be eventually
leveraging lld for a microcontroller project as well. So far
I’m working on the compiler back-end and using vendor’s linker,
but switching to lld will be the next logical step.

Cheers, Kuba Ober

On Mar 14, 2014, at 7:40 AM, Rodolphe Suescun <rsu.medal at dolphin.fr> wrote:

> Hi again,
> 
> Le 14/03/2014 11:13, Michael Spencer a écrit :
>> On Fri, Mar 14, 2014 at 1:59 AM, Rodolphe Suescun <rsu.medal at dolphin.fr> wrote:
>>> We already have a solution for the "objcopy" part (added the
>>> required output format to llvm-objdump).
>> Interesting solution. Would it be much work to implement an
>> llvm-objcopy that only supports -O binary? I plan to fully implement
>> objcopy one of these days, but having just that as a start would be
>> very useful.
> 
> I must admit I didn't try to implement a clean solution for this,
> we only needed the code in some sort of hex format (and the format
> accepted by Verilog's $readmemh system task) to be used as input
> for our ISS and adding an option and the associated dump function
> to llvm-objdump was very easy.
> 
> Writing a simple llvm-objcopy tool (with necessary output formats)
> would indeed be a cleaner way of solving that problem and probably
> not a lot of work (I will have time for this next week).
> Not sure how it should cope with non-adjacent sections for binary
> format, though...
> 
> >> [...]
>> lld currently passes through DWARF sections correctly and executables
>> are debuggable. However It does not merge debug info or construct any
>> acceleration tables. So debugging works fine, you just get giant debug
>> sections.
> 
> That's fine for us (and excellent news since I believed debug info
> were not processed at all).
> 
> Thanks a lot,
> Rod