linux - 为什么在x86_64 ABI中选择地址0x400000作为文本段的开头？

在p的this文件中。 27它说文本段开始于
0x400000。为什么选择这个特定地址？有没有
原因是什么？在GNU ld的Linux中选择了相同的地址:

$ ld -verbose | grep -i text-segment
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;

令人惊讶的是，此地址在32位x86可执行文件中更大:

$ ld -verbose | grep -i text-segment
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x08048000)); . = SEGMENT_START("text-segment", 0x08048000) + SIZEOF_HEADERS;

我读了this question，其中讨论了为什么选择0x080xxxxx地址
对于i386，但无法解释x86_64中的更改。很难找到
关于这个问题的任何解释。有人知道吗？

最佳答案

底线: amd64在使用大地址时存在一些技术限制，建议将地址空间的较低2GiB专用于代码和数据，以提高效率。因此，堆栈已被移出该范围。

在 i386 ABI 1

堆栈位于代码之前，从0x8048000下面向下逐渐增加。它提供了“超过128 MB
用于堆栈，大约2 GB用于文本和数据”(第3-22页)。

动态分段从0x80000000(2GiB)，

开始

和内核占据了顶部的“保留区域”，规范允许该区域最多达到1GiB，至少从0xC0000000(p。3-21)(which is what it typically does)开始。

主程序不需要与位置无关。

不需要实现来捕获空指针访问(第3-21页)，但是可以合理地预期128MiB(即288KiB)上方的某些堆栈空间将被保留用于此目的。

amd64(whose ABI被公式化为对i386 one的修订(第9页))具有更大的地址空间(48位)，但是大多数指令仅接受32位立即数操作数(包括直接地址和跳转指令中的偏移量) ，需要更多的工作和效率较低的代码(尤其是在考虑到指令的相互依赖性时)才能处理更大的值。作者总结了解决这些局限性的措施，并介绍了一些他们建议用来“允许编译器生成更好的代码”的“代码模型”。 (第33页)

具体来说，它们的第一个是“小代码模型”，建议使用“范围从0到231-224-1或从0x00000000到0x7effffff的地址”，这允许一些非常有效的相对引用和数组迭代。这是1.98GiB，对于许多程序来说已经足够了。

“中等代码模型”基于前一个模型，将数据分成上述边界下的“快速”部分和“慢速”其余部分，这需要特殊的指令来访问。而代码仍在边界之内。

而且，只有“大”模型不对大小做任何假设，要求编译器“使用movabs指令，如中等
代码模型，甚至用于处理文本部分中的地址。此外，当分支到其地址的地址时，需要间接分支
当前指令指针的偏移量未知。”他们继续建议将代码库拆分为多个共享库，因为这些措施不适用于偏移量已知在范围内的相对引用(如“小位置独立代码”所述)模型”)。

因此，将堆栈移动到共享库空间(0x80000000000，128GiB)下，因为其地址绝不是立即操作数，始终是间接引用的，或始终是另一个引用的lea/mov引用的，因此仅适用相对偏移限制。

上面解释了为什么将加载地址移到较低的地址。现在，为什么将其精确地移到0x400000(4MiB)？在这里，我空了一下，总结一下我在ABI规范中阅读的内容，我只能猜测它感觉“恰到好处”:

它足够大，可以捕获任何可能的不正确的结构偏移量，允许使用amd64进行操作的较大数据单元，但又足够小，不会浪费很多宝贵的地址空间起始2GiB。

等于迄今为止最大的实际页面大小，并且是人们可以想到的所有其他虚拟内存单元大小的倍数。

1请注意，随着时间的流逝，实际的x32 Linuxes已经偏离了这种布局more和more。但是我们在这里谈论的是ABI规范，因为amd64一个正式基于它，而不是任何派生的布局(请参阅其段落以获取引用)。