Question

.data和.bss的对齐有时是4个字节，有时是32个字节。示例1：根据下面输出的最后一列，bss和数据的对齐是32字节

bash-3.00$ readelf --sections libmodel.so
There are 39 section headers, starting at offset 0x1908a63c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
...
  [25] .data             PROGBITS        01e221e0 1e211e0 26ca54 00  WA  0   0 32
  [26] .bss              NOBITS          0208ec40 208dc34 374178 00  WA  0   0 32
...

示例2：根据以下输出，对齐os .data和.bss是4个字节

bash-3.00$ readelf --sections ./a.out
There are 28 section headers, starting at offset 0x78c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
...
  [22] .data             PROGBITS        0804956c 00056c 000034 00  WA  0   0  4
  [23] .bss              NOBITS          080495a0 0005a0 000004 00  WA  0   0  4
...

是什么决定了.bss和.data的对齐方式？为什么有时是4个字节，有时是32个字节？

Answer 1

我认为那些不同的对齐值是由各自的ld脚本确定的。

libmodel.so：section .data align=16, section .bss align=16
a.out：section .data align=4, section .bss align=4

Answer 2

为什么有时是4个字节，有时是32个字节？

将可执行文件加载到内存后，将通过进程虚拟地址进行寻址。对齐约束是由虚拟地址寻址引起的。例如，如果查看elf的手册页，请查看sh_addralign的说明。这就是为什么不同的精灵对象指定不同的对齐要求的原因。您可以通过更改a.out的源来进行实验，以包含double，并查看对齐是否更改。

注意：这仅适用于内存对齐。对于实际的磁盘文件也存在对齐限制。为什么？我想这将有助于在阅读文件后帮助轻松将文件数据映射到内核结构。如果我在这里错了，其他人可以纠正我。

更新：想澄清一个问题。虚拟地址对齐是必要的，因为芯片组强制执行底层内存访问粒度。因此，针对不同体系结构编译的相同程序可能会导致差异对齐限制。

Answer 3

这是一本非常好的书，它不仅可以让您更好地理解您的问题，还可以了解与之相关的所有问题。

本书的网站是here

第n章。 7是你正在寻找的那个。

我不知道你是想要一个直接的答案，还是一个更复杂的答案，但我希望它有所帮助。

Answer 4

对于bss，使用数据类型的大小来决定对齐，如果它没有对齐，则链接器首先对齐可以放置bss start的变量地址。

如何确定.data和.bss的对齐方式

4 个答案: