动态加载/链接库的内存布局

Question

Linux系统加载共享库时，共享库的内存布局是怎样的？

例如，原始内存布局如下：

+-----------+
|heap(ori)  |
+-----------+
|stack(ori) |
+-----------+
|.data(ori) |
+-----------+
|.text(ori) |
+-----------+

当我 dlopen 时foo.so，内存布局是 A 还是 B？

A
+-----------+
|heap(ori)  |
+-----------+
|stack(ori) |
+-----------+
|.data(ori) |
+-----------+
|.text(ori) |
+-----------+
|heap(foo)  |
+-----------+
|stack(foo) |
+-----------+
|.data(foo) |
+-----------+
|.text(foo) |
+-----------+

或者

B
+-----------+
|heap(ori)  |
+-----------+
|heap(foo)  |
+-----------+
|stack(foo) |
+-----------+
|stack(ori) |
+-----------+
|.data(foo) |
+-----------+
|.data(ori) |
+-----------+
|.text(foo) |
+-----------+
|.text(ori) |
+-----------+

或者除了A和B之外的任何东西......？

Answer 1

答案是“其他”。您可以通过cat /proc/self/maps. 在我的 64 位 Arch 笔记本电脑上::

00400000-0040c000 r-xp 00000000 08:02 1186758                            /usr/bin/cat
0060b000-0060c000 r--p 0000b000 08:02 1186758                            /usr/bin/cat
0060c000-0060d000 rw-p 0000c000 08:02 1186758                            /usr/bin/cat
02598000-025b9000 rw-p 00000000 00:00 0                                  [heap]
7fe4b805c000-7fe4b81f5000 r-xp 00000000 08:02 1182914                    /usr/lib/libc-2.21.so
7fe4b81f5000-7fe4b83f5000 ---p 00199000 08:02 1182914                    /usr/lib/libc-2.21.so
7fe4b83f5000-7fe4b83f9000 r--p 00199000 08:02 1182914                    /usr/lib/libc-2.21.so
7fe4b83f9000-7fe4b83fb000 rw-p 0019d000 08:02 1182914                    /usr/lib/libc-2.21.so
7fe4b83fb000-7fe4b83ff000 rw-p 00000000 00:00 0
7fe4b83ff000-7fe4b8421000 r-xp 00000000 08:02 1183072                    /usr/lib/ld-2.21.so
7fe4b85f9000-7fe4b85fc000 rw-p 00000000 00:00 0
7fe4b85fe000-7fe4b8620000 rw-p 00000000 00:00 0
7fe4b8620000-7fe4b8621000 r--p 00021000 08:02 1183072                    /usr/lib/ld-2.21.so
7fe4b8621000-7fe4b8622000 rw-p 00022000 08:02 1183072                    /usr/lib/ld-2.21.so
7fe4b8622000-7fe4b8623000 rw-p 00000000 00:00 0
7ffe430c4000-7ffe430e5000 rw-p 00000000 00:00 0                          [stack]
7ffe431ed000-7ffe431ef000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

您可以看到可执行文件被加载到低内存中，显然是 .text 段、只读数据和 .bss。差不多就是“堆”。在更高的内存中，C 库和“ELF 文件解释器”、“ld-so”被加载。然后是堆栈。无论加载了多少共享库，任何给定的地址空间都只有一个堆栈和一个堆。cat似乎只加载了 C 库。

这样做cat /proc/$$/maps将使您获得从中调用的 shell 的内存映射cat。任何外壳都将有一些动态加载的库，但zsh并bash会在大量加载。你会看到只有一个“[heap]”和一个“[stack]”。

如果调用dlopen()，共享对象文件将被映射到比 更高地址的地址空间中/usr/lib/libc-2.21.so。有一些“依赖于实现”的内存映射段，其中mmap()显示了返回的所有地址。有关漂亮的图形，请参阅内存中的程序剖析。

的来源/usr/lib/ld-2.21.so有点棘手，但它与dlopen(). dlopen()不是二等公民。

"vdso" 和 "vsyscall" 有点神秘，但是这个 Stackoverflow 问题有一个很好的解释，维基百科也是如此。