Search code examples
clinux64-bit

addresses in a 64-bit process on Linux


I wrote a (to show the problem) a simple C-pgm which has a function func() in the source code and another function funcs() in a shared lib; the compilation is done with:

$ gcc -shared -fPIC -o libfuncs.so -m64 -g funcs.c
$ gcc -g -m64 -fPIC -o stack stack.c -L. -lfuncs

i.e. it's a 64-bit compiled phm and shared lib:

$ file stack libfuncs.so
stack:       ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.0.0, BuildID[sha1]=bf7a7e15181e110789a4ee0b237f3a8ec58d4823, not stripped
libfuncs.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f1ffa166db952b92479c36169252e5ddff01e19e, not stripped

When I examine this with gdb I have the questions: Why the 64-bit addr char *p is shown as 0x400734 or after a malloc() as 0x602010, I would expect 8 bytes as it is for the char *p in the shared lib, shown as 0x7ffff7bd9609:

Breakpoint 1, main () at stack.c:12
12         char *p = "hello";
(gdb) n
14         p = (char *) malloc(10);
(gdb) p p
$1 = 0x400734 "hello"
(gdb) n
16         func(p, "foo");
(gdb) p p
$2 = 0x602010 ""
(gdb) s
func (p=0x602010 "", s=0x40073a "foo") at stack.c:25
25         char *a = "bla";
(gdb) n
27      }
(gdb) p a
$3 = 0x40073e "bla"
(gdb) n
main () at stack.c:17
17         funcs(p, "foo");   // this is a shared lib
(gdb) s
funcs (a=0x602010 "", b=0x40073a "foo") at funcs.c:8
8           char *p = "bar";
(gdb) n
10      }
(gdb) p p
$4 = 0x7ffff7bd9609 "bar"

Solution

  • When code runs under gdb, address space layout randomization is disabled for easier debugging and reproducibility. This makes it easier to pack all relevant allocation bits into the first 32 bit addresses.

    There is nothing special about it, and with big-enough allocations you will start seeing higher addresses.

    Try printing the pointers in the code, rather than in gdb, and see how it goes.

    Note: assess space layout randomization does not necessarily mean that allocations can't reside in the lower 32 bit addresses, just that randomization takes part of the space. Also, it depends on the actual address randomization algorithm.