讲重定位之前先得把静态链接这顶帽子戴正。很多写了几年业务的同学天天跟动态库、静态库打交道但真被问到链接器到底做了什么为什么报错会报 relocation truncated-fPIC 不加会怎样这类问题十有八九会卡壳。这篇东西原本是我整理给团队内新人的入门材料后来觉得值得拿出来好好写一写。这里说的重定位是编译链接体系里的重定位不是导航定位、机器人重定位、SLAM 重定位那套概念两个世界同名不同命先别搞混了。1. 静态链接到底在链什么目标文件里的半成品世界1.1 编译器只负责各写各的链接器才负责拼在一起我们写 C 代码时天然有一个错觉认为main.c里调用了foo()只要foo()定义在bar.c里编译器就知道怎么接上。实际上编译器根本不知道。C 编译器编译main.c时只负责把它变成main.o这是一个目标文件object file里面记录的call foo指令根本还没填上foo的真实地址。你可以把.o文件理解成一篇写了批注的文章到处是此处待填、见第 X 段的注释真正的页码要等排版师傅来定。这个排版师傅就是链接器。静态链接说到底是三件事把一堆.o文件里的代码段.text、数据段.data、.bss、.rodata按规则合并进最终可执行文件的对应段把符号函数名、全局变量名的引用解析到真实的定义地址把这些地址回填进原来留空的位置。第 2、3 步合起来就是标题里的重定位。1.2 段section是目标文件的基本组织单位想要理解重定位先要看懂目标文件是怎么组织的。用readelf -S看任意一个.o会看到一长串 section 头但真正重要的就那么几个.text编译出的机器码.rodata只读数据比如字符串字面量、const全局量.data已初始化的可读写全局变量.bss未初始化或零初始化的全局变量不占文件空间只占内存.symtab符号表.rela.text、.rela.data这就是重定位表的藏身之处.rela.*这一段是理解重定位的关键。.o文件里所有留了批注、待填地址的位置都会在对应的.rela段里记一条记录写明第几条指令、需要哪种修正方式、依赖哪个符号。1.3 为什么一定要到链接期才能定地址有人可能会问编译器自己不能决定地址吗它不能。因为编程语言允许模块独立编译main.o编的时候bar.o里到底有多大、.o之间的排列顺序、前面的代码占多少字节编译器一概不知。编译器只能猜一个临时地址比如从 0 开始排。如果把各个.o里相同段都从 0 开始排拼到一起必然冲突所以必须有一个全局统筹者把每个.o的段按整体布局放到最终地址空间里然后再把之前的临时地址统统修正一遍。这一整套机制就叫重定位。2. 重定位的完整机制符号表、重定位表与地址修正链2.1 一条引用指令的完整旅程我特别建议你把一个最简单的例子亲手走一遍。写三个文件// a.c int global_val 42; void helper(void) { global_val 1; }// b.c extern int global_val; extern void helper(void); int main(void) { helper(); return global_val; }然后执行gcc -c a.c b.c打开b.o里的反汇编objdump -dr b.o你会看到类似这样0000000000000000 main: 0: f3 0f 1e fa endbr64 4: 55 push %rbp 5: 48 89 e5 mov %rsp,%rbp 8: e8 00 00 00 00 call d main0xd 9: R_X86_64_PLT32 helper-0x4 d: 48 8b 05 00 00 00 mov 0x0(%rip),%rax 14: R_X86_64_PC32 global_val-0x4 14: R_X86_64_REX_GOTPCRELX global_val-0x4每一条地址还没填的指令后面都会跟着一行R_X86_64_XXX 符号名这就是重定位条目。CPU 眼里call指令后面的 4 字节现在全是 0执行必然跳到错误的地方去链接器手里的重定位表就是一张待办清单把哪些位置该填什么符号、距离都写得清清楚楚。2.2 链接器拿到重定位表之后的四步操作以主流 x86-64 ELF 平台为例链接器处理一条重定位条目时需要取四个输入来算r_offset目标文件里哪个位置的地址要被修正比如第 9 字节处的 call 偏移r_info包含符号表索引和重定位类型S符号最终在可执行文件里的地址A重定位条目里附加的加数addend。最常见的R_X86_64_PC32计算公式是S A - P其中P是当前指令所在位置在最终文件里的地址。这个公式的本质是算到目标的距离因为 x86 的 RIP 相对寻址mov 0x0(%rip), %rax本来就需要存一个偏移量而不是绝对地址。理解了S A - P你就同时理解了 ELF 里一半以上的重定位类型。2.3 符号解析失败就是那堆 undefined reference链接器把重定位表逐条处理时每条都要去查符号表。如果目标符号在整个参与链接的目标文件、静态库里都找不到定义就会出现让人脑壳疼的undefined reference to xxx。这是链接器在告诉你批注写了见第 N 段但最终页面里根本不存在第 N 段。反过来如果一个全局符号被两个.o都定义了那就是multiple definition——同一个名字贴了两张不同的内容链接器无法选择只能报错。这里有个很关键但常被忽略的认知重定位不是链接器单方面的魔法而是一套编译期生成、链接期消费、运行期起效的契约。编译器在.o里产出重定位记录相当于亮出需求清单链接器照着清单去采购和安装运行期 CPU 按最终填好的地址老实执行。三层各管一段缺一不可。3. 从只读数据到代码段x86-64 平台上的典型重定位类型3.1 不同类型对应不同算地址策略用readelf -r看目标文件重定位条目里最常出现的类型有这几类类型全称计算公式典型场景R_X86_64_64绝对 64 位地址S A取全局变量地址存进指针R_X86_64_PC32PC 相对 32 位地址S A - PRIP 相对寻址R_X86_64_PLT32通过 PLT 的调用S A - Pcall 外部函数R_X86_64_GOTPCREL通过 GOT 项访问G GOT A - P访问全局变量PIC 模式R_X86_64_32绝对 32 位地址S A普通小数据绝对寻址R_X86_64_64好理解直接把 S 的地址抄进去就完事。R_X86_64_PC32则要减去当前地址 P因为 x86-64 特别喜欢 RIP 相对寻址——指令拿到的不是目标在哪而是目标离我差多远。只要编译器产出的是偏移量形式就算整个程序被加载到任何地方距离不变就能正常工作这为后面的 PIE位置无关可执行文件打下基础。3.2 静态链接里为什么也会有 GOT 和 PLT你可能以为 GOT 和 PLT 是动态链接的专利。错。现代 Linux 默认开启 PIEgcc -fPIE -pie就算静态链接模式下的代码也往往带有位置无关的特性。GOT全局偏移表本质是一张运行期可修正的指针表PLT过程链接表则是一个跳板。静态链接里如果可执行文件自己就是 PIE 的链接器仍然可能借助 GOT/PLT 来适配外部模块可能独立加载的边界场景。你真正要知道的是PIE 模式下链接器填的常常不是绝对地址 S而是去 GOT 查、去 PLT 跳的间接路径。3.3 一个手工验证的地址计算演示拿前面b.o里那个R_X86_64_PLT32 helper-0x4来说链接后objdump -d里能看到call已经变成一个具体的call 401120 helper或call 1030 helperplt。如果链接最终结果是helper在 0x401120call 指令位于 0x401005下一条指令位于 0x40100a那么按S A - PA 取 -4P 取下一条指令地址 0x40100a得到0x401120 - 4 - 0x40100a 0x112。你会在机器码里看到 4 字节补码12 01 00 00小端序表示 0x112正好跳进helper。这就是重定位从批注变成定稿的过程无聊但极其确定。4. 静态链接完整链路的三个关键阶段4.1 地址空间布局段合并与虚拟地址分配静态链接器如 GNU ld拿到一堆输入.o后第一步不是急着算重定位而是布局。它把输入文件的.text按输入顺序收集成一个大的.text把.data收集成一个大的.data再按照链接脚本决定各个段最终放在虚拟内存的哪个位置。默认链接脚本的常见安排是.text从某地址起步、.rodata随后、.data再跟、.bss垫底。链接器手里有一张最终地址地图之后每条重定位条目都用这张地图来计算地址。有一个常见的误区很多人以为.bss段在二进制文件里占空间。实际上.bss只有符号没有内容文件里不占字节加载时由内核和程序加载器分配零页。重定位同样会作用于.bss上的符号——全局指针变量初值为 0、但在运行时被赋值指向某个全局变量时那个赋值指令里同样需要填全局变量的地址。4.2 符号解析与强符号弱符号符号解析不是简单地找到一个就行。C/C 语境里函数和已初始化全局变量默认是强符号未初始化全局变量是弱符号。多个目标文件都定义同一个符号时强符号赢弱符号两个都是强符号直接报 multiple definition。这套规则最早源自 Unix C 的公共块扩展后来被 ELF 规范吸收为符号类型与绑定的语义基础。理解这点遇到链接期没有报错但运行时某个全局变量变来变去的诡异问题时你会第一时间想到是不是弱符号冲突在作祟。4.3 重定位应用与检测布局完成、符号解析结束链接器就逐条处理重定位表。处理过程中可能暴露一堆问题最典型的就是relocation truncated to fit。造成这个错误的常见原因是某个重定位类型只支持 32 位偏移/地址但布局算出来的差值超过 2GB 或 4GB。比如R_X86_64_32只能吃下 32 位绝对地址如果链接镜像里数据太大符号地址超过 4GB就算不出来。解决办法简单粗暴加-fPIC或-fPIE改用 PC 相对寻址或者把那个模块重构成小一点的单元真要找罪魁祸首ld -Map生成内存映射文件看看各段到底排了多大。5. 从重定位到可执行文件静态链接的最终产物与加载模型5.1 页对齐、起始地址与入口点最终可执行文件的布局不是纯线性的还要考虑页对齐。现代 Linux 用 4KB 页ELF 段在文件里的p_offset和加载到内存的p_vaddr保持某种同余关系p_vaddr % 页大小 p_offset % 页大小以保证 mmap 加载时不需要做边界拆包。链接器在重定位阶段之前就已经把这种对齐约束写进程序头表里了。这也是为什么链接脚本里经常看到. ALIGN(4096);这种写法——它不只是美观问题是程序能够被正确加载的物理约束。5.2 静态链接产物的加载模型静态链接的产物里所有依赖库的代码和数据都已经直接拷贝进最终 ELF 的段里了。加载时内核把整个文件映射进内存把入口地址交给动态链接器非 PIE 静态程序则直接交给入口_start。这个过程几乎没有再解析的空间地址在链接期就已经定死或已经做成位置无关形式。好处是启动快、单二进制可部署、版本冲突少坏处是二进制大、无法共享公共库内存、升级库必须重链。5.3 静态链接下问重定位还会发生吗这是一个值得说透的问题。如果静态链接产物是非 PIE 的传统可执行文件那么链接完毕之后程序加载运行时不会再有新的链接期重定位——所有地址都已经填成绝对地址或相对偏移。如果产物是 PIE 静态可执行文件重定位类型里凡是绝对地址的条目加载器在装载时可能仍需做一次基址重定位即在固定值上加一个加载基址偏移但这已经是运行时加载器的活了。总之静态链接是把所有待定事项提前终结在生成可执行文件的那一刻之后系统负责的是装载不再负责解析外部符号。6. 实操踩坑从 readelf 到运行验证的完整排查思路6.1 常用工具链与查看方法排查重定位相关问题我固定的三板斧是readelf、objdump、ld -Map。想快速知道一个目标文件里都有哪些待重定位条目readelf -r x.o想对照指令位置看重定位挂在哪一条上objdump -dr x.o想看最终可执行文件里的每个符号落在哪个地址nm -n a.out想看内存布局和符号地址映射的完整清单ld -Mapmap.txt然后找映射里的Linker script and memory map一节。我自己排查某个全局变量为什么多花了 0x1000 字节某个符号地址怎么超大导致重定位溢出时几乎都是这三样轮着来。6.2 一个典型排查案例relocation truncated to fit假设你有一个大程序把所有.o静态链在一起突然报relocation truncated to fit: R_X86_64_32 against symbol big_table defined in .data section in xxx.o先别急着加-fPIC。先readelf -S看big_table所在的.data有多大再看整个.text、.data排布后符号地址是不是已经超过 2GB/4GB。如果只是单个大数组太大考虑改成运行时分配内存malloc而不是静态分配如果是整体太大考虑拆开几个静态库把一部分改为动态链接。加-fPIC能解决部分场景是因为 PC 相对重定位的偏移计算是 32 位带符号距离通常不会超但引入-fPIC也会带来 GOT 间接访存代码效率和体积都会变化不要把它当作万能药。6.3 静态链接 ASLR 的关系很多人问静态链接可执行文件是不是就不支持 ASLR地址空间布局随机化这是个很微妙的点。传统非 PIE 静态可执行文件加载基址固定数据段/代码段地址固定ASLR 对非 PIE 程序几乎无效但启用 PIE 的静态可执行文件在加载时仍能被装载器搬到一个随机基址靠前面说的重定位类型自适应PC 相对形式不受影响。所以当代发行版的 GCC 默认-fPIE -pie后即便底层是静态链接ASLR 仍然能起作用——前提是你的代码没有用绝对地址硬编码。如果你的嵌入式场景没有 PIE 条件静态链接的地址固定性反而是可预期性的优势。7. 为什么说理解重定位就是理解链接器的账本7.1 静态链接是地址的集中清算我把重定位表比作账本里面每一行都是一笔待销账谁欠谁一个地址、按什么汇率重定位类型折算、在什么位置销账。静态链接把所有这些账在构建期全部清算完产物干干净净不再依赖外部符号。这也是它与动态链接最根本的分野动态链接只做部分销账剩下的债留到装载期靠动态链接器和ld.so去处理换来的是二进制体积、多版本共存能力、按需加载的灵活性。7.2 对日常开发的启发理解重定位不只是为了应付笔试面试。它直接影响你写代码的习惯全局变量尽量少用不只因为线程安全还因为每次访问都可能触发 GOT 间接访存让缓存局部性变差static修饰符不是只为隔离更是把符号的可见性锁在编译单元内减少链接器符号解析的负担也降低被意外同名覆盖的风险排查疑难崩溃时看到RIP指向一个离所有段都远的地址脑子里要立刻闪过可能反汇编时有未覆盖的重定位或者直接的野指针然后info files、info symbol、x/i $pc三步走。7.3 从重定位延伸出去动态链接、PIC、LTO 与函数重排重定位机制不只是静态链接专用。动态链接的重定位条目同样写在.rela.plt、.rela.dyn里只是解析时机延后并且多了 PLT/GOT 的懒绑定优化。LTO链接时优化会直接在链接期进行跨目标文件的优化但这要求所有参与文件都有 GIMPLE 中间表示而 GIMPLE 之外的汇编文件不具备优化前提。理解了重定位的基础往上读 PIE、往下读加载器源码都不会吃力。我个人建议想深入的人把一个最小 C 程序从汇编到链接的每一条指令地址变化全走几遍手算一两轮S A - P这块基础真是花一晚上、受益几年的投资。8. 最后的实操心得写到这里我不打算做什么总结只想分享几个被同事反复问到的细节。第一阅读符号表一定要分清楚定义与引用。nm输出里T表示代码段已定义符号U表示未定义引用。一个.o里的U并不代表错误真正报错要等链接器按重定位表全部解析完。所以看到undefined reference第一时间去查的是库顺序静态库在命令行上的顺序真的会影响解析、目标文件是否漏了参与链接、符号是否被static锁在了别的编译单元里。静态库链接有个坑库内目标文件会被按需抽取库里一个.o如果只被依赖一个符号就会整体拉进来可能带进大量死代码这也是为什么很多项目要配合-ffunction-sections -Wl,--gc-sections来瘦身。第二不要对 PIE 环境下的静态链接掉以轻心。你以为它快其实因为每访问一个外部函数都可能多个 PLT/GOT 跳转或者因为-fPIE的代码生成约束比普通代码更严格性能损耗不是零。做嵌入式部署、做启动时间优化时这几点都得实测别只看链接方式的名字。第三手算一次重定位。这个方法非常土但对建立地址-距离-类型-公式的心智模型极其有效。我建议你拿一个 10 行以内的小 C 程序加-S看汇编、加-c出目标文件、readelf -r看重定位表、objdump -dr看指令与条目绑定然后跟随ld的最终布局手工验证一个 PC 相对加数。做完这一步再回去看 GDB 里那些奇怪的地址你会觉得整个世界都清晰了很多。这大概就是静态链接-重定位这六个字背后最核心的骨架。它不是某个孤立知识点而是连接编译器、链接器、加载器、运行时的一根主线。搞懂它你再看二进制可执行文件时看到的就不再是一团乱码而是一张账目分明的地址规划表。