[LLVMdev] LLD improvement plan

[Daniel Dilts]

On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com> wrote:

> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com> wrote:
> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com> wrote:
> >
> > Take a look at how debuggers have migrated through the years.  They too
> >>
> >> used to have their own script format.  Now most (all?) popular debuggers
> >> do scripting through embedding an actual programming language.  This
> >> could be a better way forward for linkers as well -- embed Python in the
> >> linker, define a Python API for linkable item placement, entry point,
> >> symbol operations, etc..., and then you also have the rest of Python at
> >> your fingertips.
> >
> >
> > I mostly care about specifying address where specific symbols will be
> placed
> > and specifying the memory layout of the platform.   I normally use
> > __attribute__((section(""))) to place the symbols in their own sections
> and
> > then use the linker script to place the sections at the required
> addresses.
> > How would this be accomplished without linker scripts?
> >
> >
> > I’d prefer to use an "__attribute__((address(0x1234)))” myself.  That way
> > you can control platform specifics with #ifdefs.
>
> But that way you have to do layout by hand in C. Generally you won't
> know the size of the preceding code or data so you won't know what
> address to put things at at the granularity of a single C level
> object/function. Better to say "put this in the ROM section" and set
> the address of the ROM section once in a linker script and let the
> linker do the layout.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/5554da77/attachment.html>