[LLVMdev] Is address space 1 reserved?

[David Chisnall]

On 8 Jan 2015, at 03:26, Sahasrabuddhe, Sameer <sameer.sahasrabuddhe at amd.com> wrote:
> 
> This sounds similar to a problem we face in the HSAIL backend. NULL is not a constant in HSAIL, but an instruction that returns "a constant address that is guaranteed to be invalid for the given address space". The instruction will always return the same constant, so it can be stored and used in a comparison. So in HSAIL, zero is a valid address that is not required to coincide with NULL. It would be incorrect to say that "null is dereferenceable" or that an object "resides at null" just because its address is zero.

For CHERI, we've had a similar issue, but we do treat null and inttoptr 0 as generating something that C regards as a null pointer.  In our model, pointers are not integers, so null and inttoptr 0 in the address space that we use for memory capabilities provide values that are not integers, but which are guaranteed not to compare equal to any valid capability.

I'm happy to share more details about this.  They'll be appearing in an ASPLOS paper in a couple of months and are in the latest revision of our ISA reference.  Getting the C semantics right required some refinements to our ISA.

C requires that (void*)0 generates a pointer that does not compare equal to any valid pointer.  It does not require that (void*)foo, where foo is an int of value 0 but not an integer constant expression, give the same value, but this is one issue where the abstract machine and real code do not always agree.  I would strongly advice (based on spending much of the last year or so researching the exact requirements for a C abstract machine that can run real code) any architecture that might want to be a C target reserving the pointer value that is numerically 0 as invalid, even if it means starting globals at address 1 (of 4 or 8 or whatever alignment forces them to be).

David