为什么 Linux 二进制文件的虚拟内存地址从 0x8048000 开始?

发布于 2024-09-03 21:07:39 字数 371 浏览 4 评论 0原文

在 Ubuntu x86 系统上反汇编 ELF 二进制文件时,我不禁注意到代码(.text)部分从虚拟地址 0x8048000 开始,并且所有较低的内存地址似乎都未使用。

这似乎相当浪费,所有 Google 出现的都是 涉及 STACK_TOP 或防止空指针取消引用的民间传说。后一种情况看起来可以通过使用单个页面来修复,而不是留下 128MB 的间隙。

所以我的问题是 - 对于为什么布局被固定为这些值是否有明确的答案,或者它只是一个任意的选择?

Disassembling an ELF binary on a Ubuntu x86 system I couldn't help but notice that the code(.text) section starts from the virtual address 0x8048000 and all lower memory addresses seem to be unused.

This seems to be rather wasteful and all Google turns up is either folklore involving STACK_TOP or protection against null-pointer dereferences. The latter case looks like it can be fixed by using a single page instead of leaving a 128MB gap.

So my question is this - is there a definitive answer to why the layout has been fixed to these values or is it just an arbitrary choice?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

⊕婉儿 2024-09-10 21:07:39

来自链接器和加载器一书:

在 386 系统上,文本基地址为 0x08048000,这允许在文本下方有相当大的堆栈,同时仍保留在地址 0x08000000 上方,从而允许大多数程序使用单个二级页表。 (回想一下,在 386 上,每个二级表映射 0x00400000 个地址。)

From the Linkers and loaders book:

On 386 systems, the text base address is 0x08048000, which permits a reasonably large stack below the text while still staying above address 0x08000000, permitting most programs to use a single second-level page table. (Recall that on the 386, each second-level table maps 0x00400000 addresses.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文