C 理解某些ELF文件结构

来自ARM信息中心，关于章节：

和来自：

表4-7，映射符号
名称含义
$a-ARM指令序列的开始
$d—数据项序列的开始（例如，文字池）

如您所见，

ELF

文件包含一个部分，其中连续地址中有代码（

bar

），然后是数据/ro（

32796

），然后是更多代码（

foo

）

现在，关于任何软件文件结构的一个基本原则是，软件由不同且独立的部分组成—

文本

（code）、

数据

，以及

bss

。（如果我们想学究的话，

rodata

），如果我们检查

MAP

文件就可以看到

所以，这个ELF结构不符合这个基本原理，所以我的问题是这里发生了什么？我是否误解了这个基本原则？如果不是，那么这

ELF

结构将在运行时更改，以满足分段分离的要求吗？ 为什么

ELF

部分在特定的顺序地址空间中包含混合类型

---

注意：我假设示例中使用的分散文件是默认文件，因为包含示例的文档没有随示例一起提供任何分散文件。

在运行时，这些部分并不重要，只有程序头中的

PT\u LOAD

段。ELF规范在那里也是非常灵活的，但是一些加载程序对它们可以处理的

PT\u加载

段有限制

---

以这种方式拆分代码和数据的原因可能是，这种体系结构只支持有限范围的PC相对寻址，并且需要一个常量池来加载大多数常量（因为通过即时消息构建它们太昂贵）。拥有尽可能少的大常量池是很有吸引力的，因为它可以提高数据和指令缓存的利用率（而不是缓存类型不正确且永远无法使用的内存），但如果代码大小超出了可以直接寻址的范围，则可能还需要多个大常量池。

在运行时，这些部分并不重要，只有程序头中的

PT\u LOAD

段。ELF规范在那里也是非常灵活的，但是一些加载程序对它们可以处理的

PT\u加载

段有限制

---

以这种方式拆分代码和数据的原因可能是，这种体系结构只支持有限范围的PC相对寻址，并且需要一个常量池来加载大多数常量（因为通过即时消息构建它们太昂贵）。拥有尽可能少的大常量池是很有吸引力的，因为它可以提高数据和指令缓存的利用率（而不是缓存类型不正确的内存，并且永远无法使用），但是，如果代码大小超出了可以直接寻址的范围，您可能仍然需要多个部分。

为什么elf文件会首先关注这些部分？这是一个编译器内部的概念。Elf和其他文件格式是关于加载二进制文件的。显然，如果你对一个elf文件进行objdump，它会显示每个部分，信息就在那里，请继续挖掘。但是加载更有趣，如果将这些部分组合成一个线性可加载块，我希望该文件在单个块（PROGBITS）中包含这些部分。与arm文档相比，我最初更担心通用elf，如果您发现通用elf中未包含的内容，然后接触arm文档。同样，你把arms工具链上的arm文档和gnu工具链混淆了？单独的工具链，可以以不同的方式遵循他们想要的任何规则，只要提供正确的结果（这意味着他们按照您使用的语言将代码实现为功能正确的代码）。为什么elf文件会关心这些部分呢？这是一个编译器内部的概念。Elf和其他文件格式是关于加载二进制文件的。显然，如果你对一个elf文件进行objdump，它会显示每个部分，信息就在那里，请继续挖掘。但是加载更有趣，如果将这些部分组合成一个线性可加载块，我希望该文件在单个块（PROGBITS）中包含这些部分。与arm文档相比，我最初更担心通用elf，如果您发现通用elf中未包含的内容，然后接触arm文档。同样，你把arms工具链上的arm文档和gnu工具链混淆了？单独的工具链可以以不同的方式遵循他们想要的任何规则，只要提供正确的结果（这意味着它们按照您使用的语言将代码实现为功能正确的代码）。

** Section #1 'ER_RO' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]
Size : 28 bytes (alignment 4)
Address: 0x00008000
$a
.text
bar
    0x00008000: E59f000C .... LDR r0,[pc,#12] ; [0x8014] = 0x801C
    0x00008004: E5901000 .... LDR r1,[r0,#0]
    0x00008008: E2411001 ..A. SUB r1,r1,#1
    0x0000800C: E5801000 .... STR r1,[r0,#0]
    0x00008010: E12FFF1E ../. BX lr
$d
    0x00008014: 0000801C .... DCD 32796
$a
.text
foo
    0x00008018: EAFFFFF8 .... B bar ; 0x8000