关于Linux中程序的内存布局

我对Linux中程序的内存布局有一些疑问。我从各种来源（我正在阅读“从头开始编程”）了解到，每个部分都加载到它自己的内存区域中。首先在虚拟地址0x8048000处加载文本部分，然后立即加载数据部分，接下来是bss部分，然后是堆和堆栈

为了试验布局，我在汇编中编制了这个程序。首先，它打印一些标签的地址并计算系统断点。然后它进入一个无限循环。循环增加一个指针，然后尝试访问该地址的内存，在某个点上，分段错误将退出程序（我故意这样做）

以下是节目：

.section .data

start_data:
str_mem_access:
.ascii "Accessing address: 0x%x\n\0"
str_data_start:
.ascii "Data section start at: 0x%x\n\0"
str_data_end:
.ascii "Data section ends at: 0x%x\n\0"
str_bss_start:
.ascii "bss section starts at: 0x%x\n\0"
str_bss_end:
.ascii "bss section ends at: 0x%x\n\0"
str_text_start:
.ascii "text section starts at: 0x%x\n\0"
str_text_end:
.ascii "text section ends at: 0x%x\n\0"
str_break:
.ascii "break at: 0x%x\n\0"
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 $8, %esp
# print address of end_text label
pushl $end_text
pushl $str_text_end
call printf
addl $8, %esp
# print address of start_data label
pushl $start_data
pushl $str_data_start
call printf
addl $8, %esp
# print address of end_data label
pushl $end_data
pushl $str_data_end
call printf
addl $8, %esp
# print address of start_bss label
pushl $start_bss
pushl $str_bss_start
call printf
addl $8, %esp
# print address of end_bss label
pushl $end_bss
pushl $str_bss_end
call printf
addl $8, %esp
# get last usable virtual memory address
movl $45, %eax
movl $0, %ebx
int $0x80

incl %eax # system break address
# print system break
pushl %eax
pushl $str_break
call printf
addl $4, %esp

movl $start_text, %ebx

loop:
# print address
pushl %ebx
pushl $str_mem_access
call printf
addl $8, %esp

# access address
# segmentation fault here
movb (%ebx), %dl

incl %ebx

jmp loop

end_loop:
movl $1, %eax
movl $0, %ebx
int $0x80

end_text:

这是输出的相关部分（这是Debian 32位）：

我的问题是：

1） 为什么我的程序从地址0x8048190开始，而不是0x8048000？有了这个，我想“_start”标签上的指令不是第一个要加载的，那么地址0x8048000和0x8048190之间是什么呢

2） 为什么文本部分的结尾和数据部分的开头之间有间隙

3） bss的起始地址和结束地址相同。我假设这两个缓冲区存储在其他地方，对吗

---

4） 如果系统断点在0x83b4001，为什么我在0x804a000之前得到分段错误？

我假设您是使用

gcc-m32-nostartfiles segment bounds.S

或类似的代码构建的，所以您有一个32位动态二进制文件。（如果您实际使用的是32位系统，则不需要

-m32

，但大多数想要测试这一点的人将使用64位系统。）

我的64位Ubuntu15.10系统在一些方面与您的程序给出的数字略有不同，但总体行为模式是相同的。（不同的内核或仅仅是不同的内核解释了这一点。brk地址变化很大，例如，

0x9354001

或

0x82a8001

）

---

1） 为什么我的程序从地址0x8048190开始，而不是0x8048000

如果构建静态二进制文件，则

\u start

将位于0x8048000

我们可以从

readelf-a a.out

中看到

0x8048190

是.text部分的开始。但它并不在映射到页面的文本段的开头。（页面是4096B，Linux要求映射在文件位置的4096B边界上对齐，因此，以这种方式布置文件，

execve

不可能将

\u start

映射到页面的开头。我认为Off列是文件中的位置。）

假定

.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） 为什么文本部分的结尾和数据部分的开头之间有间隙

为什么不呢？它们必须位于可执行文件的不同段中，因此映射到不同的页面。（文本是只读和可执行的，并且可以映射共享。数据是可读写的，必须是映射私有的。顺便说一句，在Linux中，默认情况下数据也是可执行的。）

留出一个间隙，让动态链接器可以将共享库的文本段映射到可执行文件的文本旁边。这也意味着进入数据段的越界数组索引更有可能出错。（更早、更嘈杂的故障总是更容易调试）

---

3） bss的起始地址和结束地址相同。我假设这两个缓冲区存储在其他地方，对吗

那很有趣。它们在bss中，但是IDK为什么当前位置不受

.lcomm

标签的影响。可能它们在链接之前会进入不同的小节，因为您使用了

.lcomm

而不是

.comm

。如果我使用use

.skip

或保留空间，我会得到您期望的结果：

.section .bss
start_bss:
#.lcomm buffer, 500
#.lcomm buffer2, 250
buffer:  .skip 500
buffer2: .skip 250
end_bss:

即使不切换到BSS部分，也会将内容放入BSS。i、 e.它不关心当前部分是什么，也可能不关心或影响

.bss

部分中的当前位置。TL:DR：当您手动切换到

.bss

时，请使用

.zero

或

.skip

，而不是

.comm

或

.lcomm

---

4） 如果系统断点在0x83b4001，为什么我在0x804a000之前得到分段故障

这告诉我们文本段和brk之间有未映射的页面。（您的循环以

ebx=$start\u text

开始，因此它在文本段后第一个未映射页面的上出现故障）。除了文本和数据之间的虚拟地址空间中的漏洞外，数据段之外可能还有其他漏洞

---

内存保护具有页面粒度（4096B），因此出现故障的第一个地址始终是页面的第一个字节。

几乎完全脱离主题，如果您从未读过的话——这是一个很好的读取。请注意，ELF加载程序只关心可执行文件的段。在许多情况下都有1:1的映射，比如

.text

部分（链接后）是文本段中唯一的内容。链接器将

.rodata

等节合并到

.text

中。此外，“堆”实际上并不存在，更多的是一个概念（使用mmap（MAP_ANONYMOUS）的分配与

brk

不相邻）。我不确定人们是否认为BSS和静态数据是堆的一部分。也不确定Linux是否将首字母

brk

放在BSS之后。我将

作为break.S-o break.o&&ld-dynamic linker/lib/ld Linux.so.2-o break-break.o-lc

构建在Debian 3.5 i386虚拟机中（主机是Ubuntu 15.10 64位）。@saga.x：是的，这相当于

gcc-m32-nostartfiles

。为什么会

.section .bss
start_bss:
#.lcomm buffer, 500
#.lcomm buffer2, 250
buffer:  .skip 500
buffer2: .skip 250
end_bss: