关于Linux中程序的内存布局
About the memory layout of programs in Linux
我对Linux中一个程序的内存布局有一些疑问。我从各种来源（我正在阅读 "Programming from the Ground Up"）得知每个部分都被加载到它自己的内存区域。 text 部分首先加载到虚拟地址 0x8048000，紧接着加载 data 部分，接下来是 bss 部分，然后是堆和堆栈。
为了试验布局，我用汇编编写了这个程序。首先它打印一些标签的地址并计算系统断点。然后进入死循环。循环递增一个指针，然后它尝试访问该地址的内存，在某个时候分段错误将退出程序（我是故意这样做的）。
这是程序：
.section .data
start_data:
str_mem_access:
.ascii "Accessing address: 0x%x\n[=11=]"
str_data_start:
.ascii "Data section start at: 0x%x\n[=11=]"
str_data_end:
.ascii "Data section ends at: 0x%x\n[=11=]"
str_bss_start:
.ascii "bss section starts at: 0x%x\n[=11=]"
str_bss_end:
.ascii "bss section ends at: 0x%x\n[=11=]"
str_text_start:
.ascii "text section starts at: 0x%x\n[=11=]"
str_text_end:
.ascii "text section ends at: 0x%x\n[=11=]"
str_break:
.ascii "break at: 0x%x\n[=11=]"
end_data:
.section .bss
start_bss:
.lcomm buffer, 500
.lcomm buffer2, 250
end_bss:
.section .text
start_text:
.globl _start
_start:
# print address of start_text label
pushl $start_text
pushl $str_text_start
call printf
addl , %esp
# print address of end_text label
pushl $end_text
pushl $str_text_end
call printf
addl , %esp
# print address of start_data label
pushl $start_data
pushl $str_data_start
call printf
addl , %esp
# print address of end_data label
pushl $end_data
pushl $str_data_end
call printf
addl , %esp
# print address of start_bss label
pushl $start_bss
pushl $str_bss_start
call printf
addl , %esp
# print address of end_bss label
pushl $end_bss
pushl $str_bss_end
call printf
addl , %esp
# get last usable virtual memory address
movl , %eax
movl [=11=], %ebx
int [=11=]x80
incl %eax # system break address
# print system break
pushl %eax
pushl $str_break
call printf
addl , %esp
movl $start_text, %ebx
loop:
# print address
pushl %ebx
pushl $str_mem_access
call printf
addl , %esp
# access address
# segmentation fault here
movb (%ebx), %dl
incl %ebx
jmp loop
end_loop:
movl , %eax
movl [=11=], %ebx
int [=11=]x80
end_text:
这是输出的相关部分（这是 Debian 32 位）：
text section starts at: 0x8048190
text section ends at: 0x804823b
Data section start at: 0x80492ec
Data section ends at: 0x80493c0
bss section starts at: 0x80493c0
bss section ends at: 0x80493c0
break at: 0x83b4001
Accessing address: 0x8048190
Accessing address: 0x8048191
Accessing address: 0x8048192
[...]
Accessing address: 0x8049fff
Accessing address: 0x804a000
Violación de segmento
我的问题是：
1) 为什么我的程序从地址 0x8048190 而不是 0x8048000 开始？有了这个，我猜“_start”标签上的指令不是第一个加载的东西，那么地址 0x8048000 和 0x8048190 之间是什么？
2) 为什么文本段的结尾和数据段的开头有空隙？
3）bss起止地址相同。我假设这两个缓冲区存储在其他地方，这是正确的吗？
4) 如果系统断点在0x83b4001，为什么我在0x804a000 处更早出现段错误？
我假设您正在使用 gcc -m32 -nostartfiles segment-bounds.S 或类似工具构建它，因此您有一个 32 位动态二进制文件。 （如果您实际使用的是 32 位系统，则不需要 -m32，但大多数想要测试它的人都将拥有 64 位系统。）
我的 64 位 Ubuntu 15.10 系统在某些方面给出的数字与您的程序略有不同，但总体行为模式是相同的。 （不同的内核，或者只是 ASLR，解释了这一点。brk 地址变化很大，例如，值像 0x9354001 或 0x82a8001）
1) Why is my program starting at address 0x8048190 instead of 0x8048000?
如果您构建静态二进制文件，您的 _start 将位于 0x8048000。
我们从readelf -a a.out可以看出，0x8048190是.text部分的开始。但它不在映射到页面的文本段的开头。 （页面为 4096B，Linux 要求映射在文件位置的 4096B 边界对齐，因此以这种方式布置文件，execve 不可能映射 _start 到页面的开头。我认为关闭列是文件中的位置。）
推测 .text 部分之前的文本段中的其他部分是动态链接器所需的只读数据，因此将其映射到同一页的内存中是有意义的。
## part of readelf -a output
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 08048114 000114 000013 00 A 0 0 1
[ 2] .note.gnu.build-i NOTE 08048128 000128 000024 00 A 0 0 4
[ 3] .gnu.hash GNU_HASH 0804814c 00014c 000018 04 A 4 0 4
[ 4] .dynsym DYNSYM 08048164 000164 000020 10 A 5 1 4
[ 5] .dynstr STRTAB 08048184 000184 00001c 00 A 0 0 1
[ 6] .gnu.version VERSYM 080481a0 0001a0 000004 02 A 4 0 2
[ 7] .gnu.version_r VERNEED 080481a4 0001a4 000020 00 A 5 1 4
[ 8] .rel.plt REL 080481c4 0001c4 000008 08 AI 4 9 4
[ 9] .plt PROGBITS 080481d0 0001d0 000020 04 AX 0 0 16
[10] .text PROGBITS 080481f0 0001f0 0000ad 00 AX 0 0 1 ########## The .text section
[11] .eh_frame PROGBITS 080482a0 0002a0 000000 00 A 0 0 4
[12] .dynamic DYNAMIC 08049f60 000f60 0000a0 08 WA 5 0 4
[13] .got.plt PROGBITS 0804a000 001000 000010 04 WA 0 0 4
[14] .data PROGBITS 0804a010 001010 0000d4 00 WA 0 0 1
[15] .bss NOBITS 0804a0e8 0010e4 0002f4 00 WA 0 0 8
[16] .shstrtab STRTAB 00000000 0010e4 0000a2 00 0 0 1
[17] .symtab SYMTAB 00000000 001188 0002b0 10 18 38 4
[18] .strtab STRTAB 00000000 001438 000123 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
2) Why is there a gap between the end of the text section and the start of the data section?
为什么不呢？它们必须在可执行文件的不同段中，因此映射到不同的页面。 （文本是只读和可执行的，可以是 MAP_SHARED。数据是可读写的，必须是 MAP_PRIVATE。顺便说一句，在 Linux 中，默认情况下数据也是可执行的.)
留出空间让动态链接器有空间将共享库的文本段映射到可执行文件的文本旁边。这也意味着数据部分的越界数组索引更有可能发生段错误。 （更早和更嘈杂的故障总是更容易调试）。
3）bss起止地址相同。我假设这两个缓冲区存储在其他地方，这是正确的吗？
这很有趣。它们在 bss 中，但我不知道为什么当前位置不受 .lcomm 标签影响。可能它们在链接之前位于不同的小节中，因为您使用 .lcomm 而不是 .comm。如果我使用 .skip 或 .zero 保留 space，我会得到你期望的结果：
.section .bss
start_bss:
#.lcomm buffer, 500
#.lcomm buffer2, 250
buffer: .skip 500
buffer2: .skip 250
end_bss:
.lcomm 将内容放入 BSS，即使您不切换到该部分也是如此。即它不关心当前部分是什么，并且可能不关心或影响 .bss 部分中的当前位置。 TL:DR：当你手动切换到.bss时，使用.zero或.skip，而不是.comm或.lcomm。
4) If the system break point is at 0x83b4001, why I get the segmentation fault earlier at 0x804a000?
这告诉我们在文本段和 brk 之间有未映射的页面。 （您的循环以 ebx = $start_text 开始，因此它在文本段之后的第一个未映射页面上出错）。除了文本和数据之间的虚拟地址空洞 space 之外，数据段之外可能还有其他空洞。
内存保护具有页面粒度 (4096B)，因此出错的第一个地址将始终是页面的第一个字节。
我对Linux中一个程序的内存布局有一些疑问。我从各种来源（我正在阅读 "Programming from the Ground Up"）得知每个部分都被加载到它自己的内存区域。 text 部分首先加载到虚拟地址 0x8048000，紧接着加载 data 部分，接下来是 bss 部分，然后是堆和堆栈。
为了试验布局，我用汇编编写了这个程序。首先它打印一些标签的地址并计算系统断点。然后进入死循环。循环递增一个指针，然后它尝试访问该地址的内存，在某个时候分段错误将退出程序（我是故意这样做的）。
这是程序：
.section .data
start_data:
str_mem_access:
.ascii "Accessing address: 0x%x\n[=11=]"
str_data_start:
.ascii "Data section start at: 0x%x\n[=11=]"
str_data_end:
.ascii "Data section ends at: 0x%x\n[=11=]"
str_bss_start:
.ascii "bss section starts at: 0x%x\n[=11=]"
str_bss_end:
.ascii "bss section ends at: 0x%x\n[=11=]"
str_text_start:
.ascii "text section starts at: 0x%x\n[=11=]"
str_text_end:
.ascii "text section ends at: 0x%x\n[=11=]"
str_break:
.ascii "break at: 0x%x\n[=11=]"
end_data:
.section .bss
start_bss:
.lcomm buffer, 500
.lcomm buffer2, 250
end_bss:
.section .text
start_text:
.globl _start
_start:
# print address of start_text label
pushl $start_text
pushl $str_text_start
call printf
addl , %esp
# print address of end_text label
pushl $end_text
pushl $str_text_end
call printf
addl , %esp
# print address of start_data label
pushl $start_data
pushl $str_data_start
call printf
addl , %esp
# print address of end_data label
pushl $end_data
pushl $str_data_end
call printf
addl , %esp
# print address of start_bss label
pushl $start_bss
pushl $str_bss_start
call printf
addl , %esp
# print address of end_bss label
pushl $end_bss
pushl $str_bss_end
call printf
addl , %esp
# get last usable virtual memory address
movl , %eax
movl [=11=], %ebx
int [=11=]x80
incl %eax # system break address
# print system break
pushl %eax
pushl $str_break
call printf
addl , %esp
movl $start_text, %ebx
loop:
# print address
pushl %ebx
pushl $str_mem_access
call printf
addl , %esp
# access address
# segmentation fault here
movb (%ebx), %dl
incl %ebx
jmp loop
end_loop:
movl , %eax
movl [=11=], %ebx
int [=11=]x80
end_text:
这是输出的相关部分（这是 Debian 32 位）：
text section starts at: 0x8048190
text section ends at: 0x804823b
Data section start at: 0x80492ec
Data section ends at: 0x80493c0
bss section starts at: 0x80493c0
bss section ends at: 0x80493c0
break at: 0x83b4001
Accessing address: 0x8048190
Accessing address: 0x8048191
Accessing address: 0x8048192
[...]
Accessing address: 0x8049fff
Accessing address: 0x804a000
Violación de segmento
我的问题是：
1) 为什么我的程序从地址 0x8048190 而不是 0x8048000 开始？有了这个，我猜“_start”标签上的指令不是第一个加载的东西，那么地址 0x8048000 和 0x8048190 之间是什么？
2) 为什么文本段的结尾和数据段的开头有空隙？
3）bss起止地址相同。我假设这两个缓冲区存储在其他地方，这是正确的吗？
4) 如果系统断点在0x83b4001，为什么我在0x804a000 处更早出现段错误？
我假设您正在使用 gcc -m32 -nostartfiles segment-bounds.S 或类似工具构建它，因此您有一个 32 位动态二进制文件。 （如果您实际使用的是 32 位系统，则不需要 -m32，但大多数想要测试它的人都将拥有 64 位系统。）
我的 64 位 Ubuntu 15.10 系统在某些方面给出的数字与您的程序略有不同，但总体行为模式是相同的。 （不同的内核，或者只是 ASLR，解释了这一点。brk 地址变化很大，例如，值像 0x9354001 或 0x82a8001）
1) Why is my program starting at address 0x8048190 instead of 0x8048000?
如果您构建静态二进制文件，您的 _start 将位于 0x8048000。
我们从readelf -a a.out可以看出，0x8048190是.text部分的开始。但它不在映射到页面的文本段的开头。 （页面为 4096B，Linux 要求映射在文件位置的 4096B 边界对齐，因此以这种方式布置文件，execve 不可能映射 _start 到页面的开头。我认为关闭列是文件中的位置。）
推测 .text 部分之前的文本段中的其他部分是动态链接器所需的只读数据，因此将其映射到同一页的内存中是有意义的。
## part of readelf -a output
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 08048114 000114 000013 00 A 0 0 1
[ 2] .note.gnu.build-i NOTE 08048128 000128 000024 00 A 0 0 4
[ 3] .gnu.hash GNU_HASH 0804814c 00014c 000018 04 A 4 0 4
[ 4] .dynsym DYNSYM 08048164 000164 000020 10 A 5 1 4
[ 5] .dynstr STRTAB 08048184 000184 00001c 00 A 0 0 1
[ 6] .gnu.version VERSYM 080481a0 0001a0 000004 02 A 4 0 2
[ 7] .gnu.version_r VERNEED 080481a4 0001a4 000020 00 A 5 1 4
[ 8] .rel.plt REL 080481c4 0001c4 000008 08 AI 4 9 4
[ 9] .plt PROGBITS 080481d0 0001d0 000020 04 AX 0 0 16
[10] .text PROGBITS 080481f0 0001f0 0000ad 00 AX 0 0 1 ########## The .text section
[11] .eh_frame PROGBITS 080482a0 0002a0 000000 00 A 0 0 4
[12] .dynamic DYNAMIC 08049f60 000f60 0000a0 08 WA 5 0 4
[13] .got.plt PROGBITS 0804a000 001000 000010 04 WA 0 0 4
[14] .data PROGBITS 0804a010 001010 0000d4 00 WA 0 0 1
[15] .bss NOBITS 0804a0e8 0010e4 0002f4 00 WA 0 0 8
[16] .shstrtab STRTAB 00000000 0010e4 0000a2 00 0 0 1
[17] .symtab SYMTAB 00000000 001188 0002b0 10 18 38 4
[18] .strtab STRTAB 00000000 001438 000123 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
2) Why is there a gap between the end of the text section and the start of the data section?
为什么不呢？它们必须在可执行文件的不同段中，因此映射到不同的页面。 （文本是只读和可执行的，可以是 MAP_SHARED。数据是可读写的，必须是 MAP_PRIVATE。顺便说一句，在 Linux 中，默认情况下数据也是可执行的.)
留出空间让动态链接器有空间将共享库的文本段映射到可执行文件的文本旁边。这也意味着数据部分的越界数组索引更有可能发生段错误。 （更早和更嘈杂的故障总是更容易调试）。
3）bss起止地址相同。我假设这两个缓冲区存储在其他地方，这是正确的吗？
这很有趣。它们在 bss 中，但我不知道为什么当前位置不受 .lcomm 标签影响。可能它们在链接之前位于不同的小节中，因为您使用 .lcomm 而不是 .comm。如果我使用 .skip 或 .zero 保留 space，我会得到你期望的结果：
.section .bss
start_bss:
#.lcomm buffer, 500
#.lcomm buffer2, 250
buffer: .skip 500
buffer2: .skip 250
end_bss:
.lcomm 将内容放入 BSS，即使您不切换到该部分也是如此。即它不关心当前部分是什么，并且可能不关心或影响 .bss 部分中的当前位置。 TL:DR：当你手动切换到.bss时，使用.zero或.skip，而不是.comm或.lcomm。
4) If the system break point is at 0x83b4001, why I get the segmentation fault earlier at 0x804a000?
这告诉我们在文本段和 brk 之间有未映射的页面。 （您的循环以 ebx = $start_text 开始，因此它在文本段之后的第一个未映射页面上出错）。除了文本和数据之间的虚拟地址空洞 space 之外，数据段之外可能还有其他空洞。
内存保护具有页面粒度 (4096B)，因此出错的第一个地址将始终是页面的第一个字节。