[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:       Rodolphe Suescun <rsu.medal () dolphin ! fr>
Date:       2014-03-14 11:40:51
Message-ID: 5322EAC3.1010701 () dolphin ! fr
[Download RAW message or body]

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@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]