[LLVMdev] LLD improvement plan
Richard Pennington
rich at pennware.com
Wed May 6 15:10:29 PDT 2015
On 05/06/2015 03:06 PM, Sean Silva wrote:
[snip]
>
> The real use case is on platforms, like ARM, where control
> registers are mapped to a specific address range. Then it is
> useful to put an object that deals with the control registers at a
> specific address. __attribute__((address(0x1234))) can be replaced
> with a platform specific linker script. Which is better? I don't
> know, I haven't spent any time comparing them.
>
>
> There is another important use of linker scripts, namely having a
> notion of separate load and virtual addresses. This is important for
> e.g. an initialized .data section which is stored in ROM, but needs to
> be copied to writable memory.
>
> For more information on linker scripts, see my post "linker script
> findings": http://marc.info/?l=llvm-dev&m=135698146015498&w=2
>
[snip]
Nice write up Sean.
I'd like to second the notion that linker scripts are important,
especially in the embedded/kernel world. I use linker scripts to give
addresses to register blocks and to put R/W initialized data in flash
that can be copied to RAM on start up.
One cool thing about putting register addresses in linker scripts is
that you can change the placement of registers without having to rebuild
the source. For example, I have a small embedded kernel that can run in
both MMU and non-MMU mode. In the former case the peripheral registers
are mapped into the kernel's virtual address space, in the latter case
they are placed at their actual address. It is nice to be able to do
that without having to recompile drivers.
Having said that, I would be all for a new linker script format. I find
the GNU linker's scripts counter intuitive and hard to read. The lack of
linker scripts is the main thing that keeps me from being able to use
lld right now.
-Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/4ab09814/attachment.html>
More information about the llvm-dev
mailing list