ELF与虚拟地址空间：从编译链接到加载运行的全链路解析-代码聚汇网

ELF与虚拟地址空间：从编译链接到加载运行的全链路解析

陆拾贰號·2026-09-03·阅读 21 GEO检测（免费）

ELF文件虚拟地址空间Linux进程

|难度：普通|阅读约 38 分钟

我之前在调试一个跑在STM32上的裸机程序时，同组的同事问了个问题——“VSCode里用eide插件调试，编译器让你生成elf还是axf？这两个到底有什么不一样？明明我烧录用的是hex/bin啊。”那一刻我就意识到，很多人其实一直把“编译输出文件”和“程序运行时所在的内存空间”这两件事搞混了。而一旦把“Linux的ELF文件”和“虚拟地址空间”这两条线真正打通，很多看似零碎的bug、启动崩溃、链接报错，都会瞬间变得特别清晰。

这篇文章就是来干这件事的。我会从ELF文件为什么要用“虚拟地址”来组织内容说起，结合Linux用户态进程的虚拟地址空间布局，把编译、链接、加载、运行这条链路里的关键环节逐个拆开。不管你是在服务器上排查段错误，还是在嵌入式板子上调启动代码，理解ELF和虚拟地址空间的关系，都会让你的排查思路直接上升一个层级。

1. 一个让很多人卡住的困惑：ELF里的地址到底是什么地址

先从一个最容易混淆的地方说起。你用readelf -h看到某个可执行文件的入口点地址是0x401010，又看到某个嵌入式固件的.text段加载地址是0x08000000。前者让你联想到进程运行起来的某个内存地址，后者则让你以为是芯片内部Flash的物理地址。这两种理解其实都只对了一半。

1.1 同样一个文件，“烧录地址”和“运行地址”是两码事

嵌入式开发里有个概念叫LMA（Load Memory Address，加载地址）和VMA（Virtual Memory Address，虚拟内存地址）。如果你玩过STM32的标准启动流程就知道，芯片上电后从0x08000000取出复位向量，然后跳转到SystemInit，再把.data段从Flash拷贝到RAM、把.bss段清零——这里的“0x08000000”是Flash的物理映射地址，而程序运行时的栈顶、main函数实际执行的位置，却可以是在RAM里。

于是问题来了：编译器在生成机器码时，并不知道你的代码最终会被放在Flash的哪个物理地址、运行在RAM的哪个物理地址。它只负责告诉你——“当前这段代码我希望将来能运行在0x08000000这个地址附近”。这个地址就是链接器给你安排的VMA。当调试器拿着ELF文件去下载并单步调试时，它会把VMA映射到的地址当作变量和函数所在的真实内存来访问。

在Linux上其实也是一回事，只不过Linux的用户态程序把VMA藏得更深，因为页表的存在让“程序眼里看到的地址”可以直接等于“虚拟地址”，而内核负责把这层虚拟地址翻译成物理内存页。ELF文件里保存的每一段代码或数据地址，本质上都是虚拟地址，不是物理地址。搞清楚这一点，你再看ELF的任何输出，就不会再问“这个地址是内存条上的第几个字节”这种问题了。

1.2 链接器都在忙什么：从符号到“段”

要理解ELF为什么长这样，得先理解编译器的工作流。写C代码时，你引用了一个外部函数printf，编译器并不知道printf最后会落在哪个地址，它只在.o目标文件里留一个“未定义符号”的记录。等到链接器把所有.o和静态库、动态库归拢在一起时，它才会做两件关键的事：

第一件，把各个目标文件里的.text（代码）、.data（已初始化数据）、.bss（未初始化数据）等相同属性的节合并。
第二件，给合并后的每个段分配一个具体的虚拟地址范围，并更新所有符号引用，让call、jmp、mov这些指令的操作数指向真实的地址。

这个过程就是“重定位”。而链接器在分配地址时，依据的是一套脚本，比如GCC的默认链接脚本、嵌入式工程里的.ld连接脚本。脚本里规定了什么段放在前面、什么段放在后面、每个段落在哪个地址区域。于是你在ELF里看到的那些规律性极强的地址，比如x86-64的0x400000附近、ARM的0x8000附近，其实就是链接器对着链接脚本算出来的结果。

没有这个过程，是根本谈不上“地址空间”的。因为一个程序有多少代码、多少数据、需要多大栈、几块只读数据，只有链接时才知道。

1.3 0x08000000这种地址并不是厂商“瞎设定”的

嵌入式芯片的地址空间排布，有着极强的硬件原因。像Cortex-M3/M4，内部Flash被映射到0x08000000，而SRAM被映射到0x20000000。为了让CPU在取指时能直接命中Flash，厂商指定的启动地址就是Flash的映射基地址。链接脚本里为了让main、中断向量表能被硬件正确找到，就必须把VMA设成这些固定地址。

Linux则把这个思路推向了另一个极端。由于有MMU和页表，应用程序根本不需要知道物理内存在哪。链接器只需要遵守一个用户态ABI约定：栈从高地址向下生长，动态库映射在0x7f...区域，可执行文件的代码段放0x400000左右。剩下的所有“物理放哪”，都是内核的事。两种方案一个硬、一个软，但最终ELF文件里呈现出来的，都是一组经过精心安排的虚拟地址。认清这一点，你就跨过了“文件”和“运行时”之间的分界线。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 正经拆一次ELF：链接视图与加载视图的世界

我第一次用readelf完整解析ELF文件时，也被“一大堆头信息”吓到过。实际上ELF文件的结构比大多数人想象得要简单，它只做了两套索引，一套给链接器用，一套给加载器用，两者共享ELF文件的开头描述。

2.1 两个视图一根文件

ELF全称是Executable and Linkable Format，可执行与可链接格式。这个名字本身就暗示了它的双重身份：既要给链接器当原料（比如.o重定位文件），也要给操作系统当可执行程序的载体。为了让链接器和加载器都能高效工作，ELF把文件内容按两种方式组织：

section，也就是节，记录的是“编译链接层面的信息”，像符号表、重定位项、字符串表、调试信息，这些在做静态链接时才有意义。
segment，也就是段，记录的是“运行时加载层面的信息”，像哪块数据要映射成可读可执行、哪块要可读可写、入口点是什么。

加载器不关心符号表有多少个表项，它只想知道我需要把文件偏移多少、长度多少的内容，加载到虚拟地址空间的哪个位置，赋予什么权限。链接器则相反，它不需要了解段是否有可执行权限，它只关心哪个节里有哪些符号要合并、重定位表的每一条该指向哪个节。

这两套索引同时共存于同一个ELF文件里，正是ELF设计者最精彩的地方。理解这一点，你就不会再对着readelf -S和readelf -l的输出结果犯迷糊了。

2.2 ELF Header、section、segment在文件里的位置关系

一个典型的ELF文件从文件头开始，文件头里有魔数\x7fELF、类别（32位还是64位）、字节序、版本、程序头表偏移、节头表偏移等关键信息。

然后是程序头表（Program Header Table）和节头表（Section Header Table）。程序头表每一项被称为PT_LOAD或者其他类型，它描述某一段数据后续要被映射成什么样。节头表则更细，描述每个节的名字、类型、地址、偏移、对齐等。二者的关系可以理解为：节头表不参与进程加载，加载器直接看程序头表，然后按程序头表来mmap；而调试器要记录符号、变量，则主要看节头表和符号表。

文件内容本身则由各个section具体承载，比如.text、.rodata、.data、.bss、.comment、.debug_info等。由于.bss是未初始化数据，在文件里不占空间，但它的节头表项里会记录“在内存里需要多大空间”。所以你会看到一种常见现象：链接产物文件不大，但它的.bss段可能非常庞大，这在嵌入式裸机程序里尤为明显。

2.3 实战：用readelf把一个可执行文件彻底拆开

在Linux下写一个最简单的C程序，比如：

c复制#include <stdio.h>

int global_var = 42;

int main(void) {
    printf("hello from %p\n", (void *)&global_var);
    return 0;
}

编译：

bash复制gcc -g -no-pie -o hello hello.c

此时用readelf -h hello查看头部，能看到Type为EXEC，入口点一般是0x401040之类。再执行：

bash复制readelf -l hello

重点看程序头表，标准输出会包含类似这样的信息：

code复制LOAD off   0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000
LOAD off   0x0000000000000e40 vaddr 0x0000000000401e40 paddr 0x0000000000401e40

off表示该段在文件中的偏移量，vaddr表示装载到进程中的虚拟地址，paddr是物理地址。在普通Linux可执行文件里，paddr通常等于vaddr，因为用户态程序的物理地址由内核动态分配，文件中保留的物理地址字段并没有太大意义。再看Align和权限位，会发现程序的只读代码段被映射成了R E（可读可执行），数据段则是RW（可读可写）。顺着这套信息，你其实已经能够预测进程跑起来之后，它内部的地址空间大概会长什么样了。

使用readelf -S可以看到节表，readelf -s能看到符号表，objdump -d则可以把.text反汇编出来。真实排错过程中，通常先把这些命令组合起来，确定崩溃指令到底在哪个段里、对应源文件的哪个函数，再带去GDB精确追踪。一个“文件格式”的问题，往往就在这一步被定位成了“链接脚本”或“内存越界”的问题。

3. 内核接管之后：ELF怎么长成一个进程的虚拟地址空间

很多文章会把ELF和进程分开讲，导致大家背会了“ELF段”“虚拟地址空间”这两个名词，却不知道它们之间到底是怎么挂钩的。实际上，ELF只是程序在磁盘上的一种静止形态，一旦你执行./hello，内核的加载器就会亲手把它从文件变成进程地址空间里的一个个内存映射区域。

3.1 execve之后内核都干了什么

当你在shell里敲下命令时，glibc的execve系统调用最终会进入内核的do_execve，经过参数和环境变量的拷贝，到达和文件格式相关的search_binary_handler。Linux内核维护了一个“Linux支持的可执行文件格式列表”，其中ELF格式对应的处理函数叫load_elf_binary。它干的事情，基本可以粗粒度地概括为四个步骤：

读取ELF文件头，检查魔数是否正确、类别是否匹配。
遍历程序头表，找出所有PT_LOAD类型的segment。每个PT_LOAD描述一块需要被映射到进程虚拟地址空间的数据。
调用elf_map，在进程的地址空间中创建虚拟内存区域（VMA），把对应文件内容映射进去。如果某个段的文件大小小于内存大小，比如.bss，就要把剩余部分清零。
设置进程的入口点，比如把e_entry交给CPU；如果存在PT_INTERP，说明这是一个动态链接的可执行文件，内核需要先加载动态链接器，并把控制权交给动态链接器。

这里最关键的思想是：内核并不是把ELF文件像“整块拷贝”一样塞进内存，而是按段分别映射。加载器只按程序头表来映射，而且很多文件页并不会被立刻读进内存，而是建立好映射关系，等到程序真正访问到那一页时才触发缺页异常，再按需从磁盘读入。这也解释了为什么一个几百MB的大程序启动时并不会真的把几百MB全读进物理内存——懒加载机制让大多数页面都处于“虚拟存在”状态。

3.2 Linux用户态虚拟地址空间的经典版图

一个Linux用户态进程的虚拟地址空间，通常有非常固定的“势力划分”。64位x86-64下常见的用户态地址范围是0x0000000000000000到0x00007fffffffffff，地址从低到高大致是：

只读代码段与只读数据段：通常从0x400000开始，ELF可执行文件里权限为R E的段会映射到这里，紧接着是只读数据段。
数据段与BSS段：映射为RW，用于存放修改后的全局变量和静态变量。
堆（heap）：从数据段的末尾向上生长，由brk系统调用扩展。
内存映射区（mmap区域）：包括共享库、动态链接器、线程栈、mmap分配的内存，通常在高地址附近向下生长。
用户栈（stack）：初始位置往往在一个相当高的固定地址附近，向下生长。

这些区域在图上看就是一个个VMA。如果启用了ASLR（地址空间布局随机化），其中很多基地址会加上随机偏移，但相对顺序和间隔一般保持不变。你可以在程序运行中通过查看/proc/<pid>/maps来观察这些区域，很多新手第一次看这个文件会感觉像天书，其实它每一行都是一个VMA，格式是“起始地址-结束地址权限偏移量设备号 inode 路径”。

3.3 其实代码并没有“一次性装入内存”

这个认知对排查和调优特别重要。传统教科书里常看到一句“程序从磁盘加载到内存然后执行”，这句话在Linux系统的ELF加载机制下容易产生误导。由于页表的映射是惰性的，程序执行时先建立映射，真正发生物理内存分配的是后续的缺页异常。这意味着几个进程即使运行同一个动态库，它们在物理内存上还可以共享相同的只读代码页，虚拟地址却可以各自不同，这在分析内存占用和共享库冲突时非常有用。

另外，当程序发生段错误时，日志里的地址往往表现为“0x7f...”“0x55...”“0x0”。如果你能把这个地址和上面这些高低区域对照起来，大概就能判断是访问了栈上的非法地址、堆越界，还是空指针解引用。比如在/proc/PID/maps里看到某个崩溃地址落在[heap]附近偏上一点，那大概率是堆溢出后踩到了某个映射区域的前缘。

理解“ELF段被内核映射成一块块VMA”这件事，是理解虚拟地址空间最实质性的一步。所谓地址空间，并不是程序获得的一块连续大数组，而是一堆有权限、有用途、有先后顺序的VMA拼图。ELF文件则提供了这些拼图初始的轮廓。

4. 把地址空间弄明白：不同产物在不同场景下的差别

放到实际开发环境里，大家常比较Linux的ELF、嵌入式里的axf/hex/bin，还有Windows下的PE文件。虽然格式各异，但它们在“用什么视角放地址”这个问题上的逻辑是相通的。

4.1 普通Linux ELF与嵌入式裸机ELF的差别

嵌入式交叉编译链经常会生成.axf文件。axf实际上就是一种ELF变体，它比普通ELF多了更丰富的调试与加载信息，调试器可以直接从axf里读到Flash烧录地址、RAM运行地址、源码路径、寄存器变量描述等。所以回答同事的问题很简单：eide配置里选ELF还是AXF，本质上没有太明显的功能差异，很多工具链两者都支持；关键在于你用调试器加载时，文件里必须带够符号表和调试信息，调试器才知道源码对应哪条指令。而裸机工程最终烧录的hex/bin，则是一种经过裁剪的“纯数据”格式，不含任何段权限和调试信息，只能按绝对地址写入Flash，不能直接用来在调试器里做源码级调试。

裸机ELF与Linux用户态ELF还有一个显著差异：裸机ELF如果包含.data段，它的LMA与VMA往往不一样。例如LMA是Flash地址0x08000000，VMA却可能是RAM地址0x20000000。在这种情况下，你不能简单地把ELF某段直接映射进进程地址空间，而要靠启动代码在运行时把数据从Flash拷贝到RAM。Linux用户态ELF则不存在这个LMA/VMA二分问题，整个加载过程都交给内核在虚拟地址空间里完成。

4.2 为什么调试时我们需要ELF而不是bin/hex

没有调试信息的bin文件，你只能对着反汇编看裸地址。而ELF文件的节头表里保存了.debug_line等调试信息，GDB可以通过这些信息把虚拟地址对应回源文件的行号。GDB在加载可执行文件时，会解析ELF的.text段的加载地址，并用它和代码段里的符号表建立一个地址-源码映射。每当你执行break main，GDB是通过符号表查到了main在.text段中的虚拟地址；当你单步执行，它则依靠调试信息精确地完成行号映射。

这类经验放到Linux服务端排查同样适用。线上遇到的很多coredump，分析时第一步就是用file查看coredump对应的可执行文件，再用readelf -n查看NT_FILE等note段，来确认崩溃进程加载了哪些动态库以及它们的虚拟映射区间。这时候ELF文件里的程序头表又一次派上了用场。

4.3 动态链接器、GOT/PLT与地址绑定

如果你运行的是动态链接的可执行文件，它的ELF头里还会有一个PT_INTERP段，指定动态链接器的路径，比如/lib64/ld-linux-x86-64.so.2。内核发现PT_INTERP后，不会直接把控制权交给应用程序的入口，而是先把动态链接器映射进去，再由动态链接器负责加载所有依赖的共享库、执行重定位、初始化GOT表。

这种设计直接影响到我们在虚拟地址空间里看到的现象：可执行文件和共享库的地址空间是重叠交错的。一个printf的地址，只有在动态链接器完成重定位之后才是真实可用的。在分析崩溃日志时，如果某个地址落在某个.so的映射范围里，往往意味着崩溃发生在动态库代码中；如果地址落在入口程序附近但又不是任何符号地址，则可能需要考虑PLT跳转或者GOT被破坏。

从底层原理上讲清楚这个流程，是因为在实际排错中，我见过太多人只会用gdb bt，却看不懂调用栈里的模块地址为什么和nm出来的符号地址差一大截。如果你意识到“可执行文件被加载起来之后，地址会经过一次真正的虚拟地址空间重定位，所有段的基地址都不是文件里写死的那个静态值”，你自然会理解为什么gdb总要先start或run，让动态链接器完成加载，之后拿到的地址才是最终地址。

5. 用文件映射把白纸黑字变成眼见为实

理论讲了这么多，下面分享一套我测试这套机制时最喜欢的操作流程。它的思路特别简单：找一个正在运行的Linux进程，把/proc/PID/maps里看到的地址范围，和readelf -l里看到的段地址放一起对比，你会直观地体会到“ELF虚拟地址”和“进程VMA”之间的对应关系。

5.1 /proc/PID/maps里的每一行怎么读

先准备一个示例程序：

c复制#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("PID: %d\n", getpid());
    fflush(stdout);
    sleep(60);
    return 0;
}

运行它，记下PID。然后执行：

bash复制cat /proc/PID/maps

输出中每一行大致是：

code复制55d5b0a00000-55d5b0a01000 r--p 00000000 08:01 1234567 /tmp/sleep_demo
55d5b0a01000-55d5b0a02000 r-xp 00001000 08:01 1234567 /tmp/sleep_demo
55d5b0a02000-55d5b0a03000 r--p 00002000 08:01 1234567 /tmp/sleep_demo
55d5b0a03000-55d5b0a04000 r--p 00003000 08:01 1234567 /tmp/sleep_demo
55d5b0a04000-55d5b0a05000 rw-p 00004000 08:01 1234567 /tmp/sleep_demo
7f2c00000000-7f2c00002000 rw-p 00000000 00:00 0 [heap]...
7f2c83000000-7f2c83002000 r--p ... /usr/lib/x86_64-linux-gnu/libc.so.6
...
7ffc5f000000-7ffc5f002000 rw-p 00000000 00:00 0 [stack]

r-xp中的x表示可执行，r--p表示只读，rw-p表示可读写。注意同一条路径往往出现好几行，这恰好对应ELF文件里不同的段：第一行只读，第二行可执行，第三、四行又是只读，最后一行可读写。如果你用readelf -l看同一份ELF的程序头表，会发现这些区间和PT_LOAD的段划分基本吻合。区别仅在于，ASLR开起来以后，/proc/PID/maps里的起始基地址往往带了随机偏移，不再是文件里写的0x400000或0x55...。

5.2 一个示例进程的maps和ELF对照

为什么映射会出现明明是一个文件却拆成好几段的现象？答案在于ELF段权限不同。内核在创建一个VMA时，要给它设置页面权限。如果可执行代码段和只读数据段混在一个VMA里，就得把这整块VMA设置成可读可执行；可是只读数据段明显不需要可执行，严格区分有利于安全，也有利于CPU缓存和TLB效率。因此链接器和加载器共同遵守一条规则：把权限相同的段尽量紧挨着排布，并按页对齐。

我自己的检查习惯是：

bash复制readelf -l /tmp/sleep_demo
cat /proc/PID/maps

先在文件里找到每个PT_LOAD段的vaddr和文件偏移off，再在maps里找对应的起始地址。启动ASLR后，maps里的实际地址可以这样换算：实际地址 ≈ 随机基地址 + (vaddr - 第一个PT_LOAD的vaddr)。如果验证无误，说明内核确实只是给ELF文件里的每个PT_LOAD申请了一块几乎等价的虚拟地址区域。

有了这个基本认识，你在分析高CPU占用、共享库冲突甚至恶意ELF文件时，就不再是只会背0x400000、r-xp这些名词了，而是能看到每个文件页如何映射成VMA、权限如何被内核设置。

5.3 排查崩溃地址的常用思路

线上进程崩溃时，gdb bt有时候只给你一个地址，连函数符号也不全。这时候我一般会用/proc/PID/maps记录崩溃前的内存布局，再用addr2line反查地址对应的源码行。例如：

bash复制addr2line -e /tmp/sleep_demo -f 0x55d5b0a01456

它能根据ELF里的符号表和调试信息，输出具体的函数名和源文件行号。如果崩溃地址落在某个共享库里，就需要用对应共享库的路径加偏移量来解析。

还有一种常见的场景是某个进程内存无限上涨。此时用pmap -x PID就能看到[heap]和mmap区域分别涨了多少。如果增长主要来自[heap]，通常是malloc后未释放或者内存碎片严重；如果增长来自某个.so，可能是这个库的内部缓存结构在不断增长；如果增长来自[anon]区域，则可能是线程栈过多或mmap分配的临时内存没回收。整个过程说到底，就是在读懂ELF与虚拟地址空间彼此映射的基础上，把每种增长模式和对应VMA一一对上号。

6. 学习建议与面试扩展：把知识落到能力上

聊完原理和实战，最后从一个过来人的角度，说说这个话题该怎么学、怎么答。因为“ELF文件”也好，“虚拟地址空间”也好，它们不是一个孤立的背诵点，而是一张贯穿编译、链接、加载、运行和调试的大网。

6.1 自己动手锻造一份观察材料

我强烈建议你亲手制造一个“有代表性的ELF”，然后再去观察它。不要满足于写一个hello world，可以刻意写以下几种程序：

一个包含大数组且只使用前几个元素的程序，观察它的.bss段大小和实际进程内存差异。
一个调用外部动态库函数的程序，用readelf -r看重定位表，理解为什么函数地址要到运行时才能确定。
一个链接了静态库的程序，观察它和动态链接程序的文本段大小、动态段有无。
一个嵌入式交叉编译的裸机程序，用arm-none-eabi-readelf观察它的VMA/LMA分离。

另外可以自己写几个段属性奇怪的代码，比如带__attribute__((section(".my_custom")))的变量或函数，然后看它出现在节头表哪个位置。这类实验做一遍，比看十篇博文都有用。

6.2 几个高频问题的答题思路

面试或技术讨论里，“梳理一下ELF文件的结构”“Linux进程的虚拟地址空间分布”“动态链接和静态链接的差异”“什么是页表”“PIE是什么”都是高频题。答题时不需要大段背诵，而应该落到链条上。

问ELF结构：可以答“ELF文件包含链接视图的节和加载视图的段，由文件头、程序头表、节头表共同描述，链接器关注节，加载器关注段”。
问虚拟地址空间：可以答“用户态低地址到高地址分别是代码段、数据段、堆、mmap区域、栈，内核通过VMA记录映射，页表完成虚实转换”。
问动态链接：可以答“内核只看PT_INTERP，加载动态链接器，动态链接器读取共享库和重定位表，通过GOT/PLT完成延迟绑定”。

如果能把“ELF文件里保存的是虚拟地址”这个关键点放在回答的枢纽位置，老师或面试官通常会认为你对底层机制有真实理解，而不是只会背概念。这也是本文最想让你带走的一句话：ELF是文件的姿态，虚拟地址空间是进程的姿态，中间的那座桥就是“段映射”。

6.3 后续可以做的实验

如果还想再往前走一步，推荐做这几个实验：

用strace ./hello观察execve系统调用，以及程序启动时动态链接器打开的其他文件，你会看到一连串.so的访问路径。
在程序里调用mmap映射一个文件，观看/proc/PID/maps里新增了一行路径，权限是r--p或rw-p。
修改ELF文件头里的入口点，或把某个段的权限位改掉，再运行程序，验证内核是不是真的按照程序头表的描述来加载。
在GDB里输入info proc mappings、maintenance info sections，观察调试器和ELF节、VMA之间的关系。

这些都是安全可控的本地实验，却能让你对操作系统底层机制建立起非常扎实的体感。等哪天真遇到一个诡异的段错误或启动失败时，你大概率能迅速判断，问题到底出在链接期、加载期，还是运行期的内存管理上。

我在实际使用中发现，很多人对ELF和虚拟地址空间的畏惧感，并非来自概念本身多难，而在于前后顺序没有打通。先有编译期的section和虚拟地址分配，再有加载期的segment映射与VMA创建，最后才是运行期的页表翻译和懒加载。三者的核心衔接点只有一个——ELF里记录的虚拟地址，会在进程的虚拟地址空间里找到归宿。读懂这条线之后，你再去看GDB的加载日志、崩溃时的maps、甚至内核的/proc/kallsyms，都会有一种“一切尽在掌握”的感觉。下次调试器问你“需要生成elf还是axf”时，你也可以笃定地回答：“带完整调试信息的ELF，给我就对了。”