How to dereference zero address with GCC?

Question

Suppose I need to write to zero address (e.g. I've mmapped something there and want to access it, for whatever reason including curiosity), and the address is known at compile time. Here're some variants I could think of to obtain the pointer, one of these works and another three don't:

#include <stdint.h>

void testNullPointer()
{
    // Obviously UB
    unsigned* p=0;
    *p=0;
}

void testAddressZero()
{
    // doesn't work for zero, GCC detects it as NULL
    uintptr_t x=0;
    unsigned* p=(unsigned*)x;
    *p=0;
}

void testTrickyAddressZero()
{
    // works, but the resulting assembly is not as terse as it could be
    unsigned* p;
    asm("xor %0,%0\n":"=r"(p));
    *p=0;
}

void testVolatileAddressZero()
{
    // p is updated, but the code doesn't actually work
    unsigned*volatile p=0;
    *p=0; // because this doesn't dereference p! // EDIT: pointee should also be volatile, then this will work
}

I compile this with

gcc test.c -masm=intel -O3 -c -o test.o

and then objdump -d test.o -M intel --no-show-raw-insn gives me (alignment bytes are skipped here):

00000000 <testNullPointer>:
   0:   mov    DWORD PTR ds:0x0,0x0
   a:   ud2a   

00000010 <testAddressZero>:
  10:   mov    DWORD PTR ds:0x0,0x0
  1a:   ud2a   

00000020 <testTrickyAddressZero>:
  20:   xor    eax,eax
  22:   mov    DWORD PTR [eax],0x0
  28:   ret    

00000030 <testVolatileAddressZero>:
  30:   sub    esp,0x10
  33:   mov    DWORD PTR [esp+0xc],0x0
  3b:   mov    eax,DWORD PTR [esp+0xc]
  3f:   add    esp,0x10
  42:   ret

Here the testNullPointer obviously has UB since it dereferences what is null pointer by definition.

The principle of testAddressZero would give the expected code for any other than 0 address, e.g. 1, but for zero GCC appears to detect that address zero corresponds to null pointer, so also generates UD2.

The asm way of getting the zero address certainly inhibits the compiler's checks, but the price of that is that one has to write different assembly code for each architecture even if the principle of testAddressZero might have been successful (i.e. the same flat memory model on each arch) if not UD2 and similar traps. Also, the code appears not as terse as in the above two variants.

The way of volatile pointer would seem to be the best, but the code generated here appears to not dereference the address for some reason, so it's also broken.

The question now: if I'm targeting GCC, how can I seamlessly access zero address without any traps or other consequences of UB, and without the need to write in assembly?

Answer 1

As a workaround you can use the GCC option -fno-delete-null-pointer-checks that refrain the compiler to actively check for null pointer dereferencing.
While this option is intended to be used to speed-up code optimization it can be used in specific cases as this.

Answer 2

I would put the pointer into a global variable:

const uintptr_t zero = 0;
unsigned* zeroAddress= (unsigned *)zero;
void testZeroAddressPointer()
{
    *zeroAddress=0;
}

Provided you expose the address beyond the scope of optimization (so the compiler can't figure out you don't set it somewhere else), that should do the trick, albeit slightly less efficiently.

Edit: make this code independent of implicit zero to null conversion.

Answer 3

The 0 address is the C99 NULL pointer (actually the "implementation" of the null pointer, which you can often write as 0....) on all the architectures I know about.

The null pointer has a very specific status in hosted C99: when a pointer can be (or was) dereferenced, it is guaranteed (by the language specification) to not be NULL (otherwise, it is undefined behavior).

Hence, the GCC compiler has the right to optimize (and actually will optimize)

int *p = something();
int x = *p;
/// the compiler is permitted to skip the following
/// because p has been dereferenced so cannot be NULL
if (p == NULL) { doit(); return; };

In your case, you might want to compile for the freestanding subset of the C99 standard. So compile with gcc -ffreestanding (beware, this option can bring some infelicities).

BTW, you might declare some extern char strange[] __attribute__((weak)); (perhaps even add asm("0") ...) and have some assembler or linker trick to make that strange have a 0 address. The compiler would not know that such a strange symbol is in fact at the 0 address...

My strong suggestion is to avoid dereferencing the 0 address.... See this. If you really need to deference the address 0, be prepared to suffer.... (so code some asm, lower the optimization, etc...).

^{(If you have mmap-ed the first page, just avoid using its first byte at address 0; that is often not a big deal.)}

^{(IIRC, you are touching a grey area of GCC optimizations - and perhaps even of the C99 language specification, and you certainly want the free standing flavor of C; notice that -O3 optimization for free standing C is not well tested in the GCC compiler and might have residual bugs....)}

You could consider changing the GCC compiler so that the null pointer has the numerical address 42. That would take some work.