[cfe-dev] [LLVMdev] Extend llvm to fix global addresses

[John Criswell]

On 12/6/11 7:19 PM, Dan Gohman wrote:
> On Dec 6, 2011, at 3:29 PM, Peter Cooper wrote:
>
>> The best case i can think of is embedded developers needing to layout functions or globals in memory.
>> Currently they would have to resort to a linker script or assembly hacks for this.
> This proposal also requires extending object file formats and linkers,
> and this impacts a lot of people, so it would want a pretty
> compelling motivation.
>
>> But anything which avoids the horrible int* cast has to be a good thing.  For one thing it would cause alias analysis a lot of pain.
> Actually, it wouldn't cause very much pain, if any, in alias analysis.
>
> LLVM IR already assumes that programmers can't "guess" what the
> address of the stack, global variables, or heap will be. An integer
> constant casted to a pointer is assumed to be non-aliasing with
> "regular" objects in memory. This property is of utmost importance,
> because a pass like mem2reg relies on it to know that the allocas
> it wants to promote to registers don't have their addresses
> secretly taken, for example.

In some circumstances, it may be helpful to treat memory used for memory 
mapped I/O devices as special memory objects.  We did this in the SVA-OS 
work in which we wanted to know which pieces of memory are used for 
memory mapped I/O and which are used for regular memory objects.  This, 
in turn, could be used to figure out which memory objects should be 
accessible for DMA (they are reachable from I/O memory objects in the 
points-to graph) and which load/store instructions (regular loads and 
stores or special I/O loads/stores) were accessing which type of memory.

In other words, it may be desirable to tell the difference between an 
arbitrary int2ptr cast and a pointer to a memory-mapped I/O object.

One way to do this is to have the kernel/driver use an I/O allocator 
function.  This function returns a pointer like (malloc()) but takes as 
input a physical memory address and size; the returned pointer is a 
pointer to memory-mapped I/O that can be accessed by deferencing the 
pointer, either using a volatile load/store or some special I/O function.

Interestingly enough, the Linux 2.4 kernel had such a function; it 
remapped physical memory into the kernel address space and returned a 
pointer to it.

So, instead of adding the globals feature originally suggested in this 
thread, one could simply add an intrinsic or just recognize some 
function as the "I/O memory allocator" the same way that malloc() is 
recognized as a heap allocator today.  Just make it take a constant 
integer and a size, and it returns a pointer to the memory in question.

-- John T.

P.S. The relevant SVA-OS paper is at 
http://llvm.org/pubs/2009-08-12-UsenixSecurity-SafeSVAOS.html