[LLVMdev] LLD improvement plan

Sean Silva chisophugis at gmail.com
Wed May 6 13:34:25 PDT 2015


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

> On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com> wrote:
> >
> >
> > 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.
>
> Why would you want to put an object at the address of some registers?
> You would just want a cast would you not?
>
> e.g. regs = (struct MyRegBlock *)0x1234
>

This causes you to have to be constantly dereferencing, which can result in
a huge amount of syntactic overhead. CMSIS does this really consistently
and do a good job at it:
http://www.keil.com/pack/doc/CMSIS/Core/html/group__peripheral__gr.html
But it's sort of an all-or-nothing thing to organize the peripheral headers
like that, and many platforms don't (MSP430, AVR, smaller PIC's), instead
preferring to have e.g. `volatile uint8_t Foo;` for each hardware register
instead of putting things in structs.

-- Sean Silva


>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/a40d5295/attachment.html>


More information about the llvm-dev mailing list