llvm dev - Mar 2014 - [LLVMdev] Is lld the linker we need for our project ?

Hi,

We are currently developing an LLVM-based compilation toolchain
for a micro-controller, but would need some advice about whether
we should use lld as linker.

So far we managed to write a basic target handler to read ELF
files generated by llc and link them (and relocations seem to
be applied correctly).
But we have target-specific requirements:
- the program will be loaded into memory as-is, there is no
   runtime linker
- data and code must be located in different areas of memory
   so we should be able to specify a different base address for
   different sections
- parts of the code (such as interrupt vectors) must be located
   at specific addresses
- we will also need to be able to specify (in a map file) the
   address of any function or static variable

Is any of those requirements incompatible with lld ? And if not,
any hints about how to implement them (or any lld documentation
I might have missed) ?

Thanks a lot in advance,
Rod

On Tue, Mar 11, 2014 at 9:52 AM, Rodolphe Suescun <rsu.medal at
dolphin.fr> wrote:
> Hi,
>
> We are currently developing an LLVM-based compilation toolchain
> for a micro-controller, but would need some advice about whether
> we should use lld as linker.
>
> So far we managed to write a basic target handler to read ELF
> files generated by llc and link them (and relocations seem to
> be applied correctly).
> But we have target-specific requirements:
> - the program will be loaded into memory as-is, there is no
>   runtime linker
> - data and code must be located in different areas of memory
>   so we should be able to specify a different base address for
>   different sections
> - parts of the code (such as interrupt vectors) must be located
>   at specific addresses
> - we will also need to be able to specify (in a map file) the
>   address of any function or static variable
>
> Is any of those requirements incompatible with lld ? And if not,
> any hints about how to implement them (or any lld documentation
> I might have missed) ?
>
> Thanks a lot in advance,
> Rod
It sounds like you need linker scripts and objcopy -O binary.

lld currently has very limited linker script support. Support for
layout using linker scripts would need to be completed. It is
currently stubbed out in DefaultLayout.h:class ScriptLayout. I've
cc'ed Shankar who knows more about how that is intended to work.

Both Shankar and I intend to implement linker scripts eventually, but
it's not a high priority for me right now.

So to answer your question. If you need a linker right now lld isn't
really going to work for you, but your use case is definitely in scope
for lld.

- Michael Spencer

Hi,

Thanks a lot for your answer. It seems lld is still the best
solution, even if it does not work "right out of the box" for
us today.

We already have a solution for the "objcopy" part (added the
required output format to llvm-objdump).

The ScriptLayout class seems to be empty for now (on the master
branch at least), but we do not need linker scripts today.
All that is required for now is to be able to assign a fixed
address to a few atoms (the ones that will hold the reset &
interrupt vectors) and place code/data sections in code/data
memory (so we can simulate generated code and fix and optimize
our LLVM target).
I guess that can be done by adapting the DefaultLayout code in
our own Layout class, but any hint or documentation about how
to do this in a clean manner is welcome.

I have another question: are there any plans concerning debug
information ? In v3.4, the documentation says lld does not
support DWARF info, although there are debug-related sections
in lld's output.

Thanks a lot in advance,
Rod


Le 11/03/2014 20:39, Michael Spencer a écrit :
> It sounds like you need linker scripts and objcopy -O binary.
>
> lld currently has very limited linker script support. Support for
> layout using linker scripts would need to be completed. It is
> currently stubbed out in DefaultLayout.h:class ScriptLayout. I've
> cc'ed Shankar who knows more about how that is intended to work.
>
> Both Shankar and I intend to implement linker scripts eventually, but
> it's not a high priority for me right now.
>
> So to answer your question. If you need a linker right now lld isn't
> really going to work for you, but your use case is definitely in scope
> for lld.
>
> - Michael Spencer
>