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.