了解某些ELF文件结构

Question

来自ARM的信息中心，关于static linking and relocations部分：

** 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

和ELF for the ARM architecture：

  

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

如您所见，ELF文件包含一个部分，其中包含代码（bar），然后是data / ro（32796），然后是更多代码（{{1在连续的地址中。

现在，关于任何SW文件结构的基本原则是SW由不同且独立的部分组成 - foo（代码），text和data。 （如果我们想要迂腐，可以bss，我们可以看看是否检查了rodata文件。

所以，这个ELF结构与这个基本原理不一致，所以我的问题是这里发生了什么？我误解了这个基本原则吗？如果没有，那么这个MAP结构是否会在运行时更改以满足部分分离？ 为什么ELF部分在某个顺序地址空间中包含混合类型？

注意：我假设示例中使用的分散文件是默认文件，因为文档包含示例，不提供任何分散文件以及示例。

Answer 1

在运行时，这些部分无关紧要，只有程序标题中的PT_LOAD段。 ELF规范也很灵活，但有些加载器对它们可以处理的PT_LOAD段有限制。

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