13、静态链接原理：符号解析与重定位，链接器脚本

静态链接，说白了就是把一堆目标文件（.o文件）和库文件打包成一个可执行文件的过程。很多初学者觉得链接就是“把代码拼在一起”，其实没那么简单。我当年刚入行时，被一个“未定义符号”的错误折磨了两天，最后发现是链接顺序搞反了。嗯，从那以后，我就老老实实把链接原理啃了一遍。

今天咱们就聊聊静态链接的两个核心步骤：符号解析和重定位。顺便看看链接器脚本这个“幕后黑手”到底在干什么。

13.1 符号解析：找到你想要的

符号解析，就是链接器在多个目标文件中寻找符号定义的过程。每个目标文件都会导出一堆符号（函数名、全局变量名），也会引用一堆符号。链接器的任务就是：确保每个引用的符号，都能找到一个对应的定义。

举个例子，你写了个 main.c，里面调用了 printf。编译器编译 main.c 时，它只知道 printf 是个外部符号，具体在哪它不管。链接器上场后，就得去 libc.a 或者 libc.so 里找到 printf 的实现。

符号解析的规则：

  • 强符号：函数定义、已初始化的全局变量。
  • 弱符号：未初始化的全局变量（C语言中默认是弱符号）。
  • 多个强符号同名 → 链接错误。
  • 一个强符号 + 多个弱符号 → 强符号胜出。
  • 多个弱符号同名 → 任选一个（通常是第一个）。

我在项目中遇到过一个问题：两个不同的 .c 文件都定义了全局变量 int flag，一个初始化了，一个没初始化。结果链接器一声不吭地选了初始化那个，另一个文件里的 flag 值被覆盖了。调试了半天才发现。所以，全局变量尽量加 static 限制作用域，别给自己挖坑。

13.2 重定位：把地址填对

符号解析搞定后，链接器知道了每个符号的最终地址。但目标文件里的代码和数据，用的还是“相对地址”或者“临时地址”。重定位就是把这些临时地址，替换成最终的运行时地址。

重定位的核心是重定位表（Relocation Table）。每个目标文件都有一张表，记录了哪些位置需要修改，以及怎么修改。

// 一个简单的例子
// main.c
extern int global_var;
void func() {
    global_var = 42;
}

// 编译后，main.o 里的重定位条目大概长这样：
// Offset   Type              Value
// 0x10     R_X86_64_32       global_var
// 0x20     R_X86_64_PC32     func

重定位类型有很多，常见的有：

类型 含义 示例
R_X86_64_32 绝对地址重定位 全局变量地址
R_X86_64_PC32 相对地址重定位（PC相对） 函数调用
R_X86_64_GOTPCREL GOT表相对重定位 动态链接时用

你想想看，如果链接器把绝对地址和相对地址搞混了，程序跑起来直接段错误。我曾经在移植一个嵌入式系统时，因为链接器脚本里地址对齐没设对，导致重定位后的函数指针全乱了。嗯，那次加班到凌晨三点。

13.3 链接器脚本：定制你的内存布局

链接器脚本（Linker Script）是链接器的“配置文件”。默认情况下，链接器会用一套内置规则来安排各个段（.text、.data、.bss等）的位置。但有些场景下，你得自己动手写脚本。

什么时候需要自定义链接器脚本？

  • 嵌入式开发：代码要烧到Flash，运行时搬到RAM。
  • 操作系统内核：需要把内核加载到特定地址。
  • 性能优化：把热点函数放到更快的内存区域。
  • 多段加载：比如游戏引擎，部分资源按需加载。

一个典型的链接器脚本长这样：

/* 简单链接器脚本示例 */
SECTIONS
{
    . = 0x10000;  /* 起始地址 */

    .text : {
        *(.text)   /* 所有目标文件的 .text 段 */
    }

    .data : {
        *(.data)
    }

    .bss : {
        *(.bss)
    }
}

这里 . 表示当前地址计数器。你可以用 . 来手动控制每个段的起始地址。我个人习惯在脚本开头加一大段注释，说明内存布局的意图，方便后来人维护。

小技巧：用 objdump -h 查看目标文件的段信息，用 readelf -S 看更详细的段表。调试链接问题时，这两个命令是救命稻草。

13.4 静态链接的完整流程

咱们把整个流程串起来，看看静态链接到底干了哪些事：

  1. 符号解析：扫描所有输入文件，建立全局符号表。
  2. 段合并：把同名的段（如所有 .text）合并到一起。
  3. 地址分配：为每个段和每个符号分配虚拟地址。
  4. 重定位：根据重定位表，修改代码和数据中的地址。
  5. 生成可执行文件：输出 ELF 或其他格式。

下面这张图展示了核心流程：

目标文件 (.o) 静态库 (.a) 链接器脚本 (.ld) 链接器 (ld) 符号解析 → 段合并 → 地址分配 → 重定位 可执行文件 (ELF) 包含完整的符号表、重定位信息、段表

注意：静态链接会把所有用到的库函数都复制到可执行文件里。如果你的程序用了 printf，整个 printf 的实现（包括它调用的其他函数）都会被链接进来。这也是为什么静态链接生成的文件比动态链接大很多。

13.5 实战：用链接器脚本控制内存布局

咱们来看一个实际例子。假设你有一个嵌入式项目，代码要放在 Flash 的 0x08000000 地址，数据要放在 RAM 的 0x20000000 地址。链接器脚本可以这样写：

/* 嵌入式项目链接器脚本 */
MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .text : {
        *(.text)
        *(.rodata)
    } > FLASH

    .data : {
        _sdata = .;
        *(.data)
        _edata = .;
    } > RAM AT> FLASH

    .bss : {
        _sbss = .;
        *(.bss)
        _ebss = .;
    } > RAM
}

这里 > FLASH 表示运行时地址在 Flash，AT> FLASH 表示加载地址也在 Flash。对于 .data 段，它运行时在 RAM，但初始值存储在 Flash 里。启动代码需要把 .data 从 Flash 拷贝到 RAM。

我曾经在写一个 bootloader 时，因为链接器脚本里 AT> 写错了，导致 .data 段没有被正确拷贝到 RAM，全局变量全是乱的。调试了整整一个下午才发现是脚本的问题。所以，写完链接器脚本后，一定要用 objdump -h 和 readelf -l 检查段布局。

13.6 常见链接问题与排查

静态链接过程中，你可能会遇到这些问题：

  • 未定义符号：链接器找不到某个符号的定义。检查库的链接顺序，或者是不是忘了加 -l 选项。
  • 多重定义：两个目标文件定义了同一个符号。检查是不是忘了加 static，或者用 -Wl,--allow-multiple-definition 强制覆盖（不推荐）。
  • 地址溢出：比如跳转指令的偏移量超过了 32MB 范围。考虑用大地址模式，或者重新安排代码布局。
  • 段对齐问题：某些架构要求段地址对齐到 4KB 或 16KB。在链接器脚本里用 ALIGN() 函数。

调试技巧：用 ld -verbose 查看默认链接器脚本，用 ld -Map output.map 生成映射文件，里面详细记录了每个符号的地址。我每次遇到链接问题，第一件事就是看 .map 文件。

静态链接的原理，说白了就是“找符号、填地址”。链接器脚本则是你控制内存布局的“遥控器”。搞懂了这些，你就能理解为什么有时候换个链接顺序程序就崩了，为什么全局变量会被意外覆盖。嗯，这些坑我都踩过，希望你能少走弯路。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →