llvm dev - Dec 2011 - [LLVMdev] Extend llvm to fix global addresses

Hi all

It would be nice to add support for placing globals at fixed addresses in
memory.

For example, low level driver code tends to contain things like this

*(int*)0x00001000

which is horrible.

Alternatively people are using linker scripts and assembly hacks to put symbols
at fixed addresses.

I propose we add first class support to this in the compiler.  Like addrspace(#)
we should have something like fixedaddr(#) to put a symbol at the address
specified (naming is open to suggestions)

Support for this would be needed in the following places:
Clang - with suggestions open to syntax, particularly if anyone knows of
existing compilers with syntax for this
IR - "fixedaddr" as above with new attribute on globals (and probably
on functions if there's a need to bind functions to fixed addresses too)
Object files - this might be possible within current formats like ELF by doing
horrible things with relocations, but we'll have to experiment
Linker - like object file support, but additionally would be nice to improve
them to the point where we can avoid using linker scripts to do this

Comments are very welcome.

Thanks,
Pete

On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper
wrote:
> It would be nice to add support for placing globals at fixed addresses in
memory.
I don't know. From my experience, the usefulness is very, very limited.
As in: drivers are about the only thing that can make use of it.
> For example, low level driver code tends to contain things like this
> 
> *(int*)0x00001000
> 
> which is horrible.
The drivers I have seen can't work that way because they are written to
cover more than one specific machine. As soon as you go anywhere near an
IO abstraction, this doesn't apply anymore. As such, I think this
feature primarily helps making ugly, unportable code differently ugly,
unportable code.

Joerg

On Dec 6, 2011, at 6:55 AM, Joerg Sonnenberger wrote:
> On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote:
>> It would be nice to add support for placing globals at fixed addresses
in memory.
> 
> I don't know. From my experience, the usefulness is very, very limited.
> As in: drivers are about the only thing that can make use of it.
Yeah, it would mostly be drivers, but there's also plenty of embedded
processors out there
with minimal/no linkers.  In those situations the developer tends to have to
hack the assembly
output from the compiler to lay out the globals
manually.
> 
>> For example, low level driver code tends to contain things like this
>> 
>> *(int*)0x00001000
>> 
>> which is horrible.
> 
> The drivers I have seen can't work that way because they are written to
> cover more than one specific machine. As soon as you go anywhere near an
> IO abstraction, this doesn't apply anymore. As such, I think this
> feature primarily helps making ugly, unportable code differently ugly,
> unportable code.
Agreed on the ugliness, but at least it keeps it all in one place instead of
defining the globals
in C but then having to also maintain a linker script somewhere else to define
their addresses.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

(resent due to mailing list breakage)

On Dec 6, 2011, at 6:55 AM, Joerg Sonnenberger wrote:
> On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote:
>> It would be nice to add support for placing globals at fixed addresses
in memory.
> 
> I don't know. From my experience, the usefulness is very, very limited.
> As in: drivers are about the only thing that can make use of it.
I agree that most code does not profit from specifying fixed addresses for
objects.
Nonetheless, there is code which does.  Obvious examples:
 - boot-loaders
 - kernels
 - drivers
 - JITted code interacting with the runtime
 - code working with specialized address spaces
>> For example, low level driver code tends to contain things like this
>> 
>> *(int*)0x00001000
>> 
>> which is horrible.
> 
> The drivers I have seen can't work that way because they are written to
> cover more than one specific machine. As soon as you go anywhere near an
> IO abstraction, this doesn't apply anymore. As such, I think this
> feature primarily helps making ugly, unportable code differently ugly,
> unportable code.
Your argument appears to be that this feature would have little use to you.
Noted, I guess.  We've spoken to several people who do write drivers and
other code like the above, and they seem pretty enthusiastic about the
idea.  If you have input about how best to design this, at any of the levels
Peter spelled out, that would be interesting.

John.