[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [LLVMdev] Is lld the linker we need for our project ?
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2014-03-14 16:28:26
Message-ID: 949E89AB-2B55-40A7-AA70-C626347ED3C0 () mareimbrium ! org
[Download RAW message or body]

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=92m working on the compiler back-end and using vendor=92s 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@dolphin.fr> wrote:

> Hi again,
> =

> Le 14/03/2014 11:13, Michael Spencer a =E9crit :
>> On Fri, Mar 14, 2014 at 1:59 AM, Rodolphe Suescun <rsu.medal@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

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
[prev in list] [next in list] [prev in thread] [next in thread]