addresses in a 64-bit process on Linux [closed] - c

Question

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
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"

Answer 1

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.