[LLVMdev] Is lld the linker we need for our project ? (original) (raw)
Rodolphe Suescun rsu.medal at dolphin.fr
Fri Mar 14 04:40:51 PDT 2014
- Previous message: [LLVMdev] Is lld the linker we need for our project ?
- Next message: [LLVMdev] Is lld the linker we need for our project ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [LLVMdev] Is lld the linker we need for our project ?
- Next message: [LLVMdev] Is lld the linker we need for our project ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]