主页 / unix / 问题 / 474028
Accepted
John P
Asked: 2018-10-09 08:01:11 +0800 CST

为什么某些库和其他部分会在 gdb 的 linux 虚拟内存中重复？

  • 772

在此处输入图像描述

这是在 gdb 中查看进程的虚拟内存的结果；我对此有一些疑问：

  1. 为什么虚拟内存的某些部分是重复的？比如我们的程序（stack6）和libc库重复4次；如果他们将它们分成不同的部分，那为什么呢？为什么不把它们放在一起呢？

  2. 最上面的路径（/opt/pro...）是我们虚拟内存的指令部分（文本部分）并且只包含指令吗？

  3. 为什么4个libc的大小不同？偏移量是怎么回事，如果我们已经有了大小和起始地址，那么偏移量是什么？

  4. 数据、bss、内核和堆部分在哪里？为什么上图中的某些部分没有关于它们的信息？gdb 中是否有更好的选项可以实际显示所有部分？

  5. 有没有比 gdb 更好的程序可以更好地显示我们进程的虚拟内存部分？我只想对实际的虚拟内存有一个很好的了解，哪个调试程序提供了最好的结果。

我提到的部分：

在此处输入图像描述

linux process

1 个回答

  1. Best Answer

    gdb'输出中缺少一项重要信息：页面的权限。（它们显示在 Solaris 和 FreeBSD 上，但不在 Linux 上。）您可以通过查看/proc/<pid>/maps; 您的 Protostar 示例的地图显示

    $ cat /proc/.../maps
08048000-08049000 r-xp 00000000 00:0f 2925       /opt/protostar/bin/stack6
08049000-0804a000 rwxp 00000000 00:0f 2925       /opt/protostar/bin/stack6
b7e96000-b7e97000 rwxp 00000000 00:00 0
b7e97000-b7fd5000 r-xp 00000000 00:0f 759        /lib/libc-2.11.2.so
b7fd5000-b7fd6000 ---p 0013e000 00:0f 759        /lib/libc-2.11.2.so
b7fd6000-b7fd8000 r-xp 0013e000 00:0f 759        /lib/libc-2.11.2.so
b7fd8000-b7fd9000 rwxp 00140000 00:0f 759        /lib/libc-2.11.2.so
b7fd9000-b7fdc000 rwxp 00000000 00:00 0
b7fe0000-b7fe2000 rwxp 00000000 00:00 0
b7fe2000-b7fe3000 r-xp 00000000 00:00 0          [vdso]
b7fe3000-b7ffe000 r-xp 00000000 00:0f 741        /lib/ld-2.11.2.so
b7ffe000-b7fff000 r-xp 0001a000 00:0f 741        /lib/ld-2.11.2.so
b7fff000-b8000000 rwxp 0001b000 00:0f 741        /lib/ld-2.11.2.so
bffeb000-c0000000 rwxp 00000000 00:0f 0          [stack]

    （Protostar 示例在一个易于破解的 VM 中运行，大概是为了使练习易于处理：没有 NX 保护，也没有 ASLR。）

    您将在上面看到，看似重复的映射gdb实际上对应于具有不同权限的不同映射。文本段被映射为只读和可执行；数据段被映射为只读；BSS 和堆被映射为读写。理想情况下，数据段、BSS 和堆是不可执行的，但此示例缺少 NX 支持，因此它们是可执行的。每个共享库都有自己的文本段、数据段和 BSS 映射。第四个映射是不可读、不可写、不可执行的段，通常用于防止缓冲区溢出（尽管考虑到此处使用的内核和 C 库的年龄，这可能有所不同）。

    偏移量，当给出时，表示文件中数据的偏移量，它不一定与它在地址空间中的位置有很大关系。加载时，受对齐约束；例如，libc-2.11.2.so的程序头文件指定了两个“LOAD”头文件：

    Type           Offset   VirtAddr   PhysAddr   FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x00000000 0x00000000 0x13d2f4 0x13d2f4 R E 0x1000
LOAD           0x13e1cc 0x0013f1cc 0x0013f1cc 0x027b0  0x0577c  RW  0x1000

    （readelf -l用于查看此内容。）

    如果映射到段的部分具有不同的保护标志，则这些可能会导致具有不同虚拟地址的相同偏移量的多个映射。在stack6的情况下：

    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD           0x000000 0x08048000 0x08048000 0x00604 0x00604 R E 0x1000
LOAD           0x000604 0x08049604 0x08049604 0x00114 0x00128 RW  0x1000

    （这也解释了proc info mappingsfor显示的小尺寸stack6：每个标头请求小于 4KiB，对齐为 4KiB，因此它在不同地址获得两个具有相同偏移量的 4KiB 映射。）

    空白映射对应匿名映射；详情见man 5 proc。您需要闯入mmap以gdb确定它们对应的内容。

    您看不到内核映射（除了vsyscall某些架构上的遗留问题），因为从进程的角度来看它们并不重要（它们不可访问）。

    我不知道更好的gdb选择，我总是使用/proc/$$/maps.

    有关内核读取的 ELF 格式的详细信息，以及它如何映射到内存分配，请参阅程序如何运行：ELF 二进制文件；它有指向更多参考资料的指针。

    • 6

相关问题