Linux下的共享库加载地址

我对共享库有一个很大的疑问。 我研究的是，不同进程共享的库的虚拟地址对于所有这些进程是相同的。 但我试图通过使用proc文件系统通过以下一组命令来查看相同的内容：

$ cat /proc/*/maps | grep /lib/libc-2.12.1.so

输出是：

0025a000-003b1000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 003b1000-003b2000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 003b2000-003b4000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 003b4000-003b5000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 0086d000-009c4000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 009c4000-009c5000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 009c5000-009c7000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 009c7000-009c8000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00110000-00267000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 00267000-00268000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00268000-0026a000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 0026a000-0026b000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00485000-005dc000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 005dc000-005dd000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 005dd000-005df000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 005df000-005e0000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00110000-00267000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 00267000-00268000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00268000-0026a000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 0026a000-0026b000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00181000-002d8000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 002d8000-002d9000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 002d9000-002db000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 002db000-002dc000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00110000-00267000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 00267000-00268000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00268000-0026a000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 0026a000-0026b000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 0013c000-00293000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 00293000-00294000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00294000-00296000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00296000-00297000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00bf7000-00d4e000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 00d4e000-00d4f000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00d4f000-00d51000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so 00d51000-00d52000 rw-p 00159000 08:07 1046574 /lib/libc-2.12.1.so 00227000-0037e000 r-xp 00000000 08:07 1046574 /lib/libc-2.12.1.so 0037e000-0037f000 ---p 00157000 08:07 1046574 /lib/libc-2.12.1.so 0037f000-00381000 r--p 00157000 08:07 1046574 /lib/libc-2.12.1.so

对于不同的进程，相同的共享库的虚拟地址是不同的。

有人可以解释我为什么这样吗？

.so：需要找出加载时执行哪个函数

Linux上的共享库和-fPIC错误

用soname插入共享对象的一部分

有没有办法在Android中closuresdynamic加载的库？

在Windows和LINUX中创build程序库

nm报告符号被定义，但ldd报告符号是未定义的

创buildELF图像

我如何链接C中的共享对象？

链接到共享库Linux

atexit（）函数

共享库加载程序ld.so可能会根据二进制文件的需要更改加载共享库的虚拟地址，因为代码，数据和其他部分的大小可能因二进制文件而异。 重新排列地址空间的过程称为重定位 。

重定位也是为什么你必须使用gcc -fPIC将共享库编译成与位置无关的代码的原因。

共享库的相同虚拟地址来自a.out天。 ELF没有这样的限制。

另外内核随机化映射布局（参见ASLR）。