[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