[LLVMdev] LLD improvement plan

[Smith, Kevin B]

While slightly off topic of LLD improvement,

volatile uint8_t __attribute__((address(0x1234))) foo;

is slightly nicer than

(*(volatile uint8_t *)0x1234)

because the latter ends up often being done in a header file as a macro, usually as something like:

#define foo (*(volatile uint8_t *)0x1234)

The former behaves with all the language scoping rules, so a foo within a function or as a parameter has the expected
behavior.  The latter has all the downsides that macro usage can come with.

On topic – Sean – I think that is a great document on linker scripts and their usage and meaning.

Kevin Smith

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva
Sent: Wednesday, May 06, 2015 1:34 PM
To: Will Newton
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] LLD improvement plan



On Wed, May 6, 2015 at 9:34 AM, Will Newton <will.newton at gmail.com<mailto:will.newton at gmail.com>> wrote:
On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com<mailto:diltsman at gmail.com>> wrote:
>
>
> On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com<mailto:will.newton at gmail.com>> wrote:
>>
>> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com<mailto:clattner at apple.com>> wrote:
>> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com<mailto: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<mailto: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/9c382e4d/attachment.html>