为什么 linux 二进制文件的虚拟内存地址从 0x8048000 开始? [英] Why do virtual memory addresses for linux binaries start at 0x8048000?

问题描述

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

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.

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

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?

推荐答案

来自 链接器和加载器 书:

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

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.)

这篇关于为什么 linux 二进制文件的虚拟内存地址从 0x8048000 开始?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！