Question

我写了一个（展示问题）一个简单的C-pgm，它在源代码中有一个函数func（），在共享库中有另一个函数funcs（）。编译完成的是：

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

即这是一个64位已编译的phm和共享的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

当我使用gdb进行检查时，我有一个问题：为什么64位地址char *p显示为 0x400734 或在malloc（）之后显示为 0x602010 >，我希望共享库中的char *p是8个字节，显示为 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

当代码在gdb下运行时，address space layout randomization被禁用，以简化调试和再现性。这使得将所有相关分配位打包到前32位地址中变得更加容易。

它没有什么特别的，分配足够多的地址时，您将开始看到更高的地址。

尝试在代码中而不是在gdb中打印指针，并查看其运行方式。

注意：评估空间布局的随机性并不一定意味着分配不能驻留在低32位地址中，而只是说随机化占据了一部分空间。而且，这取决于实际的地址随机化算法。

Linux上的64位进程中的地址

1 个答案: