.data + .bss的ELF第二个加载段地址答案

【问题标题】：ELF second load segment address of .data + .bss.data + .bss的ELF第二个加载段地址
【发布时间】：2014-05-21 18:49:07
【问题描述】：

在这种情况下，正确的那个地址是：

.data 从0x08048054 开始直到0x08048054+0x0000e

.bss 从 0x08048054+0x0000e 开始直到 0x0804805+0x00016

还是我错过了什么？请为我澄清一下。

编辑

我使用这个命令来获取图片中的信息：

readelf -l filename

【问题讨论】：

您是否有权访问链接描述文件，还是使用默认链接描述文件编译的？如果是这样，使用了什么编译器/链接器？
问题是，除非您获得链接描述文件信息，否则您无法知道哪个先 bss 或 data重新使用 GCC 或 Clang)。
@nonsensickle：它是用旧的 C 编译器编译的。我不知道使用了链接器，但我可以尝试弄清楚。但通常.bss 先出现，这是大多数编译器的行为，在这种情况下，如果我们假设它也适用于这个编译器，我对地址是否正确？
如果您假设.bss 出现在第一位，那么.bss 将位于0x08048054，.data 将位于0x08048054+0x0000e。是的，这是一个合理的假设。
正确，库本身将包含符号信息，然后将通过您的应用程序使用的链接器脚本。因此，如果是这种情况，您实际上可以控制 .bss 和 .data 的布局顺序。

【解决方案1】：

好的，那我从哪里开始...是的，.data 和 .bss 都在内存中的那个区域中。问题是没有办法弄清楚它们的顺序。

我们可以假设遵循默认顺序并做出有根据的猜测，但我不喜欢这样。

通过您提到的问题下的冗长评论线程，您提到了一些有趣的事情，这在您的问题中并不明显。

可执行文件不是动态链接的，因为文件命令说：ELF 32 位 LSB 可执行文件，英特尔 80386，版本 1 (SYSV)，静态链接，在这种情况下被剥离，没有链接描述文件，不是吗？ – 面具

在这种情况下，库包含带有所有符号偏移的符号表。此表包括部分信息。当您编译应用程序时，它将由链接器处理。此时，您的链接器脚本控制着.data 和.bss 部分的输出顺序。

如果它是默认链接器脚本，请查找它。如果它是自定义的，您应该可以访问它并且可以阅读它。如果不确定在这里详细说明，我们会尽力提供帮助:)

我本人曾问过a question这是不相关的，但提供了链接器脚本的示例代码和一些 C 代码。在该链接器脚本中，.bss 段在.data 段之后。

【讨论】：

【解决方案2】：

您正在查看程序标题信息，而节标题可能是您需要的。程序头中可能包含许多节，您无法准确推断各个节的大小和对齐要求。

要查看部分标题，请使用：

readelf -S

【讨论】：