当我在 gdb 中打开二进制文件并输入 info proc mappings 时，我得到以下结果:
gdb$ info proc mappings
process 26732
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x8048000 0x804a000 0x2000 0x0 /gpfs/main/path/to/binary
0xb098000 0xb09a000 0x2000 0x2000 /gpfs/main/path/to/binary
0xb09a000 0xb09b000 0x1000 0x3000 /gpfs/main/path/to/binary
0xb09b000 0xb0bd000 0x22000 0x0 [heap]
0xb4d25000 0xb4efc000 0x1d7000 0x0 /usr/lib/i386-linux-gnu/libc-2.28.so
0xb4efc000 0xb4efd000 0x1000 0x1d7000 /usr/lib/i386-linux-gnu/libc-2.28.so
0xb4efd000 0xb4eff000 0x2000 0x1d7000 /usr/lib/i386-linux-gnu/libc-2.28.so
0xb4eff000 0xb4f00000 0x1000 0x1d9000 /usr/lib/i386-linux-gnu/libc-2.28.so
0xb4f00000 0xb4f03000 0x3000 0x0
0xb4f61000 0xb7fcc000 0x306b000 0x0
0xb7fcc000 0xb7fcd000 0x1000 0x0 /gpfs/main/path/to/library.so
0xb7fcd000 0xb7fce000 0x1000 0x0 /gpfs/main/path/to/library.so
0xb7fce000 0xb7fcf000 0x1000 0x1000 /gpfs/main/path/to/library.so
0xb7fcf000 0xb7fd1000 0x2000 0x0
0xb7fd1000 0xb7fd4000 0x3000 0x0 [vvar]
0xb7fd4000 0xb7fd6000 0x2000 0x0 [vdso]
0xb7fd6000 0xb7ffd000 0x27000 0x0 /usr/lib/i386-linux-gnu/ld-2.28.so
0xb7ffe000 0xb7fff000 0x1000 0x27000 /usr/lib/i386-linux-gnu/ld-2.28.so
0xb7fff000 0xb8000000 0x1000 0x28000 /usr/lib/i386-linux-gnu/ld-2.28.so
0xbffdf000 0xc0000000 0x21000 0x0 [stack]
为什么每个共享库和二进制文件本身都分成多个相邻的内存部分？
最佳答案
每一行代表一个单独的PT_LOAD段:
$ eu-readelf -l /lib/x86_64-linux-gnu/libc.so.6
[…]
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0213d8 0x0213d8 R 0x1000
LOAD 0x022000 0x0000000000022000 0x0000000000022000 0x1471d8 0x1471d8 R E 0x1000
LOAD 0x16a000 0x000000000016a000 0x000000000016a000 0x04ba08 0x04ba08 R 0x1000
LOAD 0x1b6648 0x00000000001b7648 0x00000000001b7648 0x005218 0x0091b8 RW 0x1000
[…]
通常，这些段具有不同的共享属性和权限(只读、读-执行或读写)。不同的链接编辑器可以为同一个共享库生成不同数量的加载段。例如，使用 -z separatecode option倾向于添加另一个负载段。
关于linux - 为什么在 gdb 中使用 `info proc mappings` 时同一个共享库出现多次？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57741497/