[链接器的世界-原理篇00] 从一条编译命令出发：程序如何连成整体

写下 return add(1, 2); 时，我们只需要知道函数的名字和参数。可处理器执行到这里，需要知道的是：下一步去哪个地址。

如果 add 定义在另一个文件中，编译当前文件时，这个地址往往还没有确定。那个文件可以稍后才编译，也可以早已存在于某个库里。独立生成的机器码，最后怎样接成一个能运行的程序？

这就是本系列的起点。我们将从一次跨文件调用出发，观察链接器如何寻找定义、安排代码与数据的位置、修补地址，再沿着可执行文件进入进程，理解哪些工作留到了运行时。

一条命令怎样处理两个文件

先把跨文件调用写成一个正常的程序。add.c 定义加法函数，call_add.c 中的声明给出函数的返回类型和参数类型，使编译器能检查调用；函数的实现仍然留在另一个文件里。

1
// add.c
2
int add(int a, int b) { return a + b; }

1
// call_add.c
2
int add(int a, int b);
3

4
int main(void) {
5
    return add(1, 2);
6
}

将它们保存在同一目录，在安装了 C 开发工具的 x86-64 Linux 上执行：

1
$ gcc call_add.c add.c -o app  # -o：将输出文件命名为 app
2
$ ./app
3
$ echo $?
4
3

程序没有打印文字；main 返回的 3 是退出状态，紧接着执行的 echo $? 将它显示出来。我们先用这个结果确认：一个文件中的调用确实执行了另一个文件里的函数。

这里用 GCC¹ 完成构建。接下来保留中间文件，看看两份源码是在什么时候连起来的。

命令接受两份源码，不代表某一个程序一次完成了所有工作。它首先承担编译器驱动程序（compiler driver）的职责：根据输入文件和选项，组织生成程序所需的步骤。

第一步是预处理。C 源码中的 #include 引入头文件内容，#define 定义的宏在使用处展开，条件编译决定保留哪些代码。编译器随后对预处理后的 C 代码进行语法、类型检查和优化，并生成目标处理器的指令。指令可以先写成便于人阅读的汇编语言，再由汇编器编码成 CPU 执行的机器码。这是编译与汇编两个不同的工作，即使实现它们的软件被放进了同一个程序。

每份源码经过这些步骤，得到一个目标文件，通常以 .o 结尾。它既保存机器码和数据，也保存尚未解决的跨文件引用：编译 call_add.c 时，编译器已经知道怎样传入两个整数，却还不知道 add 最终放在哪个地址。目标文件必须把这个待解决的引用留下来。

最后才是链接。链接器读取这些目标文件，找到 add 的定义，安排代码和数据的位置，修补与地址有关的引用，并生成可执行文件。驱动程序还会自动补入所需的启动代码和标准库；即使源码只有 main，操作系统交出控制权之后也还需要启动代码把执行引到 main。

可以把同一次构建拆开，让中间产物留在目录里：

1
$ gcc -c call_add.c -o call_add.o  # -c：生成目标文件后停止，不链接
2
$ gcc -c add.c -o add.o
3
$ gcc call_add.o add.o -o app
4
$ ./app
5
$ echo $?
6
3

第三条命令的输入已经是目标文件，因此驱动程序直接组织链接，不再把 C 源码编译一遍。改动 add.c 后，只需重新生成 add.o，再执行链接；call_add.o 可以复用。这正是把程序拆成文件以后，保留中间产物的价值。

想确认驱动程序实际调用了哪些工具，可以查看它准备执行的命令：

1
$ gcc -### call_add.c add.c -o app  # -###：显示内部命令，但不实际构建

输出可能包含 cc1²、as³、collect2⁴ 和 ld⁵。此时只需把它们对应到源码处理、汇编和链接这些职责上；具体名称及 GCC、Clang⁶ 的实现差异见文末附录。同样的阶段划分，不要求工具链启动同样数量的进程。

分开编译让每个文件可以独立处理，也限制了每一步能看到的信息。刚才两个文件对 add 的理解一致：两个整数进去，一个整数出来。如果同一个名字在两份源码里代表了不同的类型，这套流程还能把问题拦下来吗？

同一个名字，两种理解

设想一个变量原本是整数，某处代码却把它当成了浮点数。若定义和使用就在同一个文件里，编译器能看见冲突。把它们分到两个文件，情况就变了：main.c 分配两个整数 x、y，调用 set_x 后打印它们；other.c 只知道自己要改一个名叫 x 的变量。

1
// main.c
2
#include <stdio.h>
3

4
int y = 5;
5
int x = 7;
6

7
void set_x(void);   /* 定义在 other.c 里 */
8

9
int main(void) {
10
    set_x();
11
    printf("x = %d, y = %d\n", x, y);
12
    return 0;
13
}

1
// other.c
2
extern double x;
3

4
void set_x(void) {
5
    x = 1.0;
6
}

main.c 定义了两个全局变量 x 和 y，然后调用另一个文件里的 set_x。other.c 用 extern 声明了 x，意思是"这个变量定义在别的文件里，我只是要用它"，然后给它赋值 1.0。问题在于，main.c 里的 x 是 int，other.c 以为它是 double。

单独编译 other.c 时，编译器看不到 main.c 中的定义，只能按 extern double x 生成写入代码。这里的 extern 不分配另一份 x，它要求稍后把这次访问接到别处的定义上。

两边显然不一致。剩下的问题是，组合两个文件的那一步能不能发现它。

编译和链接都通过了

下面固定使用 x86-64 Linux、GCC 15.2 和 musl⁷ 1.2.5，以便逐字节观察同一份静态可执行文件。musl-gcc⁸ 为本机 GCC 选择 musl；它仍在这台 Linux 上编译、链接和运行。开头的普通函数调用不需要这项选择，这里引入它是为了固定后续检查的 C 库与启动代码。

先建立实验目录，再将上面的两段源码分别保存为该目录中的 main.c、other.c：

1
mkdir -p linker-example-ch00
2
cd linker-example-ch00

下面分别编译两个文件，再把它们静态链接成一个程序。这里的静态链接把所需的库代码纳入可执行文件，因此这个例子运行时不需要另找 musl 的共享库。

这两份源码的声明类型不兼容，程序具有 UB⁹。下面的输出是所列构建的一次观察，用来分析具体机器码，不是 C 语言保证的结果。

1
$ musl-gcc -O2 -Wall -Wextra -c main.c -o main.o  # -O2：优化；-Wall -Wextra：启用两组警告
2
$ musl-gcc -O2 -Wall -Wextra -c other.c -o other.o
3
$ musl-gcc -static main.o other.o -o prog  # -static：静态链接所需的库代码
4
$ ./prog
5
x = 0, y = 1072693248

编译没有一条警告，链接也没有任何报错。运行结果里，x 变成了 0，而 y 变成了一个十亿多的数。整个程序里没有任何一行代码给 y 赋过值。

这里仍用 -c 分别生成目标文件 main.o、other.o，第三条命令再组织链接，生成可执行文件 prog。最后直接执行 ./prog，编译器、链接器与加载程序使用同一台 x86-64 Linux。

这个程序已经违反了 C 对同一对象的声明必须具有兼容类型的要求，产生 UB⁹：语言标准不保证它输出任何特定数字（C11 草案 N1570，§6.2.7 第 2 段）。下面解释的是这组命令生成的机器码为何产生了这次输出，不能据此把某个输出当成此程序在所有平台上的结果。

这次观察到的结果还与编译选项有关。这一版 GCC 在 -O2 下把 main.c 的两个全局变量按源码的逆序摆放，x 在前，y 紧随其后。改用 -O0、加上 -fno-toplevel-reorder，或者换成 clang 编译，变量都按源码顺序摆放，y 落在 x 前面，这三组 Linux 实测都先打印 x = 0, y = 5，随后以 SIGSEGV 终止；y 保持原值，不代表越界写入消失。两个变量在 .data 里谁先谁后，是编译器生成 main.o 时定下的，链接器只是把这一整块数据原样搬进 prog，并不重新排列。

要解释这份产物里的两个数，需要把赋值看成一次内存写入。1.0 这个 double 的位模式是 0x3FF0000000000000，一共 8 个字节。x86-64 是小端序（little-endian）的，也就是一个多字节的数在内存里低位字节放在低地址。所以 set_x 往 x 的地址写入这 8 个字节时，低 4 个字节 0x00000000 写进了 x，x 变成 0；高 4 个字节 0x3FF00000 落到了紧随其后的 y 上，0x3FF00000 换成十进制正好是 1072693248。main.c 只给 x 留了 4 个字节，other.c 却按 8 个字节去写。

这次写入没有把浮点数转换成整数：两份机器码只是最终访问了同一个地址。把不同文件里同名的引用和定义关联起来，叫符号解析；目标文件中记录这些名字、位置和属性的条目，叫符号（symbol）。负责完成这项工作的链接器，把 other.o 对 x 的引用接到了 main.o 的定义上。

符号表可以记录对象占多少字节，却没有完整的 C 类型约束，不能凭同名就证明这次写入合法。普通的本机目标文件链接通常不会检查两边的 C 类型；开启链接期优化时，编译器可以借助保留下来的中间表示发现部分跨文件不匹配，这与只读取符号表的链接路径不同。关于检查能力的边界，GCC 的 LTO 文档专门说明了跨翻译单元类型不匹配的诊断。

眼前还有另一件事值得注意：这个程序虽然写错了，操作系统仍然把它启动起来了。链接器显然生成了一个操作系统能够接受的文件。内核检查的究竟是什么？

内核接受了怎样的文件

prog 除了机器指令和变量内容，还必须说明这些字节应当放到哪里、哪些区域允许写入、从哪个地址开始执行。内核根据这些信息建立进程，不会重新检查 C 源码。

本例以及通常的 Linux 本机工具链生成的可执行文件、目标文件和共享库使用 ELF¹⁰ 格式，它是一套规定"文件里每个字节放什么"的规范。工具 readelf¹¹ 可以把 ELF 文件的结构打印出来。下面用 -l 选项查看 prog 的程序头，-W 让每行不折断。

1
$ readelf -lW prog
2
Elf file type is EXEC (Executable file)
3
Entry point 0x40109e
4
There are 6 program headers, starting at offset 64
5

6
Program Headers:
7
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
8
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000190 0x000190 R   0x1000
9
  LOAD           0x001000 0x0000000000401000 0x0000000000401000 0x004947 0x004947 R E 0x1000
10
  LOAD           0x006000 0x0000000000406000 0x0000000000406000 0x000cc8 0x000cc8 R   0x1000
11
  LOAD           0x006fc0 0x0000000000407fc0 0x0000000000407fc0 0x000150 0x0007f8 RW  0x1000
12
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
13
  GNU_RELRO      0x006fc0 0x0000000000407fc0 0x0000000000407fc0 0x000040 0x000040 R   0x1
14

15
 Section to Segment mapping:
16
  Segment Sections...
17
   00
18
   01     .init .text .fini
19
   02     .rodata .eh_frame
20
   03     .init_array .fini_array .data.rel.ro .got .got.plt .data .bss
21
   04
22
   05     .init_array .fini_array .data.rel.ro .got .got.plt

程序头表（program header table）由若干条程序头记录组成。其中 LOAD 描述需要映射进内存的区域，其他类型则传递解释器路径、栈权限等加载信息。在 shell 里执行 ./prog 后，启动它的执行路径通过 execve 将文件交给内核。对于这个静态可执行文件，可以先沿着两类信息理解启动过程：入口地址（entry point），以及类型为 LOAD 的四行。内核还要验证 ELF 头，并处理栈权限等属性；这两类信息不是它做的全部检查。

一行 LOAD 的意思是：从文件的 Offset 处取 FileSiz 个字节，放到内存地址 VirtAddr 处，这块内存一共占 MemSiz 个字节，权限是 Flg。R 表示可读，W 表示可写，E 表示可执行。VirtAddr 是虚拟地址，也就是程序自己看到的地址，操作系统会把它映射到某块实际的物理内存上。

把四行连起来读，内核做的事情就清楚了。文件开头 0x190 个字节放到 0x400000，只读；接着 0x4947 个字节的机器码放到 0x401000，可读可执行；然后是只读数据；最后一段放到 0x407fc0，可读可写，文件里只有 0x150 个字节，内存里却要占 0x7f8 个字节，多出来的部分由内核填零。四段都放好后，内核再给程序建好栈，也就是函数调用时存放局部变量和返回地址的那块内存，并在栈上放好命令行参数和环境变量。最后它把 CPU 的指令指针（x86-64 上叫 %rip，存着下一条要执行的指令的地址）设成 0x40109e，程序就开始运行了。

GNU_STACK 这一行也会被内核读到，它声明栈要不要可执行。可执行栈指栈上的字节能被当作指令执行，这曾经是某些老技巧需要的，也给攻击者往栈上注入代码提供了方便，这里的 RW 表示不需要。其他程序头各有自己的使用者。例如 GNU_RELRO 标明重定位完成后可改为只读的范围，GNU_PROPERTY 携带处理器相关属性；它们是否以及怎样生效，要结合目标架构、内核和运行时实现判断。

下半部分的 Section to Segment mapping 是另一种视角。链接器在拼装程序时，处理的单位是节（section），比如放机器码的 .text、放已初始化全局变量的 .data、放未初始化全局变量的 .bss，其余的节后面各章讲。这里的四个 LOAD 描述可加载段（segment），一个可加载段可以覆盖若干节。常规 ELF 装载依赖程序头描述的段，不靠节名逐个装载 .text 或 .data。我们的 x 和 y 就在 .data 里，位于第四个段。

这些地址和范围由链接器写入。编译器生成的 main.o 里根本没有程序头，用 readelf -l main.o 只会得到一句 There are no program headers in this file.。0x40109e 这个入口地址、四个段的划分、每段的权限、.data 被放在 0x408000，这些全是链接器在拼装时决定的。main.o 里 x 的地址还是 0，到了 prog 里才变成 0x408008，这也是链接器算出来的。

至此能分清两件事：程序头足以让内核建立进程，却不足以证明进程执行的操作正确。类型冲突、找不到函数、找不到共享库，也不能都指望同一个组件来发现。它们分别暴露在程序形成和启动的不同阶段。

四个时期，四种错误

一个程序从源码到运行，要经过四个时期。编译期，编译器把每个 .c 文件单独翻译成目标文件；链接期，链接器把所有目标文件和库拼成可执行文件；加载期，内核和动态链接器把可执行文件放进内存，准备好运行环境；运行期，CPU 从入口开始执行指令。这里把预处理、编译和汇编合在生成目标文件这一侧；“加载期”指启动路径，运行中的 dlopen 仍然可以再次触发加载与动态链接。

这个划分对排查问题很有用，因为每个时期能看到的信息不同，能发现的错误也不同。越早的时期发现错误，报错信息越贴近源码，修起来越容易。下面用同一个小程序在每个时期各制造一个错误，观察错误究竟在哪一步被发现。为保留前面的类型不匹配示例，在它旁边建立独立目录；本节的 main.c、main.o 都属于这个新例子。

1
mkdir -p ../linker-example-phases
2
cd ../linker-example-phases

1
// add.c
2
int add(int a, int b) { return a + b; }

1
// main.c
2
int add(int a, int b);
3

4
int main(void) {
5
    return add(1, 2);
6
}

编译期：类型错误

编译器手里有一个完整的翻译单元，也就是一个 .c 文件加上它 #include 进来的全部头文件。在这个范围里，它知道每个名字的类型，可以检查调用是否和声明一致。把 main.c 里的调用改成 add(1)，另存为 bad.c：

1
$ musl-gcc -c bad.c
2
bad.c: In function 'main':
3
bad.c:5:12: error: too few arguments to function 'add'; expected 2, have 1
4
    5 |     return add(1);
5
      |            ^~~

（节选，后面还有指向声明位置的 note。）报错精确到行和列。编译器之所以能发现，是因为 add 的声明就写在同一个文件里。

链接期：undefined reference

再用正确的 main.c，这次编译单独通过，链接时却忘了带上 add.c：

1
$ musl-gcc -c main.c
2
$ musl-gcc -static main.o -o app
3
ld: main.o: in function `main':
4
main.c:(.text+0x13): undefined reference to `add'
5
collect2: error: ld returned 1 exit status

（第一行开头的 ld 原本是本机的 /usr/bin/x86_64-linux-gnu-ld.bfd 路径，这里截短了。）

这两行诊断来自前面看到的调用链：链接器 ld 报告缺少定义，GCC 的辅助程序 collect2 接着报告链接器执行失败。编译 main.c 时，编译器只看到了 add 的声明，就在 main.o 里留下一个未定义的符号 add，并在机器码里空出一个"地址待填"的位置。到了链接期，链接器在所有输入里都找不到 add 的定义，于是报错。(.text+0x13) 说的是 main.o 的 .text 节第 0x13 个字节处有个地址填不上。

换成 LLVM¹² 的 LLD¹³ 链接器，通过它处理 ELF 文件的命令 ld.lld 执行同一次缺定义检查，措辞有所不同：

1
$ ld.lld -static main.o -o /dev/null
2
ld.lld: error: undefined symbol: add
3
>>> referenced by main.c
4
>>>               main.o:(main)

普通链接过程能汇集输入目标文件的符号信息，却不会因此恢复 C 的函数声明。这里的 main.o 留下了对 add 的引用，常规符号表没有记录它接受几个参数；链接器能检查是否存在可用定义，不能据此核对这次调用的参数列表。

加载期：找不到共享库

前面的程序都是静态链接的。更常见的做法是动态链接：库代码放在一个单独的共享库文件里（Linux 上以 .so 结尾），可执行文件里只记下要用哪个库，等程序运行时再把库装进来。负责在运行前把共享库找到、装好、把地址填上的程序叫动态链接器，常简称 ld.so，在 musl 系统上它是 /lib/ld-musl-x86_64.so.1，在使用 glibc¹⁴ 的系统上通常是 ld-linux-x86-64.so.2。

把 add.c 做成共享库 libadd.so，再让 main.c 动态链接到它：

1
$ musl-gcc -shared -fPIC add.c -o libadd.so
2
$ musl-gcc main.c -L. -ladd -o calc_dyn
3
$ readelf -lW calc_dyn | grep -A1 INTERP
4
  INTERP         0x000238 0x0000000000000238 0x0000000000000238 0x000019 0x000019 R   0x1
5
      [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]
6
$ readelf -dW calc_dyn | grep NEEDED
7
 0x0000000000000001 (NEEDED)             Shared library: [libadd.so]
8
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]

-shared 让链接器输出共享库；-fPIC 让编译器生成不依赖固定加载地址的代码，因为共享库每次被装到哪里事先说不准。-L. 告诉链接器去当前目录找库，-ladd 表示链接 libadd.so。链接成功了，因为链接器在当前目录找到了 libadd.so，确认里面有 add。程序头里多出一行 INTERP，内核读到它，就知道要先把动态链接器装进来，由它接手后面的工作。动态链接器再去读 NEEDED 这两条记录，挨个寻找需要的共享库。

直接运行时，libadd.so 所在的目录不在默认的搜索路径里：

1
$ ./calc_dyn
2
Error loading shared library libadd.so: No such file or directory (needed by ./calc_dyn)
3
Error relocating ./calc_dyn: add: symbol not found
4
$ echo $?
5
127

$? 是 shell 里上一条命令的退出码，也就是 main 的返回值或者传给 exit 的那个数，0 表示成功。这里的 127 是动态链接器失败时给出的。main 的第一条指令还没执行，程序就失败了。用环境变量 LD_LIBRARY_PATH 把那个目录加进搜索路径，程序就能正常运行，退出码是 1 + 2 = 3：

1
$ LD_LIBRARY_PATH=. ./calc_dyn
2
$ echo $?
3
3

这类错误在加载期才暴露，原因很直接：链接时找得到的文件，到了运行它的那台机器上不一定还在原处。开发机上编译、链接、运行都好好的程序，拷到一台没装这个库、或者库装在别的目录的机器上，第一条指令都执行不了，部署时最常见的就是这一类报错。加载期还会拦下别的问题，比如 glibc 2.41 起，动态链接器会拒绝用 dlopen（程序在运行中途主动加载共享库的函数）加载一个声明需要可执行栈的共享库（glibc 2.41 的 NEWS）。这一项本章没有实测，只作示意。

运行期：链接成功也可能是错的

回到本章开头的程序。它在编译期、链接期、加载期都顺利通过，错误到了运行期才以"打印出一个怪数"的形式出现。这类错误最难查，因为没有任何工具在出错的那一刻报告。如果 y 是一个很少被读到的配置项，这个程序可能要过很久才露出问题。

几个例子中的检查对象并不相同。编译器按当前翻译单元中的声明检查调用；普通链接器按目标文件中的符号和重定位建立引用关系；加载器检查文件是否能够按要求映射和启动。它们都成功，也不能证明 other.c 对 x 的类型理解正确。把 extern int x 放进公共头文件，并让定义方和使用方都包含它，才使编译器有机会在各自编译时发现声明与使用的冲突。

反过来，拿到一条报错，也能从它的样子认出是哪个时期发出的。编译器的报错带着源文件名、行号和列号，比如 bad.c:5:12，因为它手里有源码。链接器的报错开头是链接器自己的名字，ld: 或者 ld.lld:，位置写成"哪个目标文件、哪个节、第几个字节"，比如 main.c:(.text+0x13)，经过 gcc 调用时最后还会跟一行 collect2。加载期的报错来自动态链接器，musl 上以 Error loading shared library 开头，这时 main 还没开始执行。运行期的错误往往根本没有报错，只有一个不对的输出，或者 shell 报告被信号终止。常见 shell 会用 128 + 信号编号 表示这种终止，但程序也能主动返回同样的数值，不能仅凭“大于 128”就下结论。排查问题的第一步，就是先认出它属于哪个时期，再去找那个时期手里有什么信息。

名字之外，链接器还决定了什么

从 other.c 的一条赋值到 prog 的程序头，中间至少有三件不同的事。链接器先确认这次访问对应哪个定义，再为定义所在的数据分配输出位置，最后把访问所需的地址或位移写进代码。这三件事通常称为符号解析、布局和重定位。

1
  main.c ──编译──▶ main.o  ─┐
2
                             ├──▶ 链接器 ──▶ prog ──▶ 加载器 ──▶ 进程
3
 other.c ──编译──▶ other.o ─┘                (可执行文件)

源码中的名字到这里有了地址，文件中的字节也有了内存位置。符号解析选错定义、布局给错权限、重定位填错位移，可能产生完全不同的症状。即使这些工作都做对，源码中的类型冲突仍然可能被原样带进进程。判断链接器是否正确，需要同时检查它如何理解输入，以及它的输出会怎样被执行。

反过来看，分开编译也带来了实际收益：修改 other.c 时可以复用 main.o，库的实现可以独立构建和分发。代价是每个半成品必须留下足够的信息，说明自己定义了什么、还需要什么、哪些位置等待修补。目标文件因此不能只是一串机器指令；链接器也不能只把文件首尾相接。

这套分工形成之前，程序同样遇到过“把别处写好的代码接进来”的需求。没有目标文件、没有符号表时，搬动一段代码，程序员就得亲手修改里面的地址。链接器的来历，要从这件具体的工作讲起。

实验环境

Linux：编译与运行在同一台机器上

ELF 主线以 x86-64 Linux 为目标。最直接的环境是一台 x86-64 Linux 主机或虚拟机：编译器生成本机机器码，Linux 内核直接加载程序。以下全部命令都在这台 Linux 机器的终端执行；从其他电脑通过 SSH 登录也一样，不在登录端生成实验产物。

先确认系统与处理器：

1
uname -sm

系统应为 Linux，处理器为 x86_64。如果是在跨架构容器里执行，uname 可能反映模拟出的架构，还要检查宿主内核和运行方式，不能仅凭这行输出判断是否原生执行。

以 Debian/Ubuntu 的原生环境为例，基础工具可以这样安装：

1
sudo apt-get update
2
sudo apt-get install build-essential binutils file gdb coreutils musl-tools clang llvm lld \
3
  python3 git strace
4
gcc -dumpmachine
5
gcc --version
6
ld --version
7
mkdir -p "$HOME/linker-lab"
8
cd "$HOME/linker-lab"
9
printf 'int main(void) { return 42; }\n' > hello42.c
10
musl-gcc -static hello42.c -o hello42
11
file hello42
12
readelf -h hello42
13
./hello42
14
echo $?

gcc -dumpmachine 的目标应包含 x86_64 和 linux；最后的退出状态应为 42。build-essential 提供 GCC、C/C++ 开发文件和 make，binutils¹⁵ 提供 ld、readelf、objdump¹⁶、nm¹⁷ 等工具。Debian 的 musl-tools提供本机架构的 musl-gcc 包装器：在本机 GCC 上选择 musl 的头文件、库和链接设置，它不是把 ARM 主机变成 x86-64 交叉编译器。

本文记录来自 Ubuntu 26.04、GCC 15.2、GNU¹⁸ binutils 2.46、Clang/LLD 21.1.8。musl-gcc 用于 musl C 实验，gcc/g++ 用于系统 glibc 与 C++ 实验；切换 C 库会改变启动文件和动态解释器，不能混用其输出。后续各篇也沿用这一 Linux 环境。

练习

“观察”使用 linker-example-ch00 中类型不匹配示例的 prog、main.o 和 other.o，不使用后面加法示例的 main.o。“预测”与 A–F 各使用独立目录；“改坏”使用类型不匹配示例的源码副本。相同文件名在各例中代表不同的输入。

观察。

1. 用 readelf -h prog 或 readelf -l prog 找出入口地址，再用 nm prog 查这个地址上是哪个符号。nm 会列出文件里的符号和它们的地址。入口是 main 吗？
2. 第四个 LOAD 段的 FileSiz 是 0x150，MemSiz 是 0x7f8。先用 readelf -lW prog 下半部分的 Section to Segment mapping 找出这个段装了哪些节，再用 readelf -SW prog 查这些节的地址和大小，解释多出来的那部分内存对应什么。
3. 分别运行 nm main.o 和 nm other.o。x 在两个文件里各显示成什么？再用 readelf -s other.o 看 x 的类型和大小一栏，能不能从中看出 other.c 以为它是 double？

预测。下面两个文件能不能链接？运行后会打印什么，还是会崩溃？先写下答案再动手。

1
// table.c
2
int table[2] = {1, 2};

1
// use.c
2
#include <stdio.h>
3

4
extern int *table;
5

6
int main(void) {
7
    printf("table[1] = %d\n", table[1]);
8
    return 0;
9
}

定位。下面六个程序各有一个错误。不要运行，先判断每个错误会在编译、链接、加载、运行哪个时期暴露。除特别说明外，都用 musl-gcc -static 把列出的文件一起编译链接。

A，单个文件：

1
#include <stdio.h>
2
int square(int n) { return n * n; }
3
int main(void) { printf("%d\n", squre(3)); return 0; }

B，两个文件都声明了一个不带初值的全局变量：

1
// a.c
2
int count;
3
void bump(void) { count++; }

1
// main.c
2
#include <stdio.h>
3
int count;
4
void bump(void);
5
int main(void) { bump(); printf("%d\n", count); return 0; }

C，main.c 想调用 util.c 里的辅助函数：

1
// util.c
2
static int helper(int n) { return n + 1; }
3
int twice(int n) { return helper(n) * 2; }

1
// main.c
2
int helper(int n);
3
int main(void) { return helper(41); }

D，头文件和定义不一致，两个 .c 都包含了头文件：

1
// scale.h
2
int scale(int v);

1
// scale.c
2
#include "scale.h"
3
long scale(long v) { return v * 10; }

1
// main.c
2
#include "scale.h"
3
int main(void) { return scale(4); }

E，把 greet.c 做成共享库，main.c 动态链接它，然后不设置 LD_LIBRARY_PATH，直接在 Linux 上运行可执行文件：

1
// greet.c
2
#include <stdio.h>
3
void greet(void) { puts("hello from libgreet"); }

1
// main.c
2
void greet(void);
3
int main(void) { greet(); return 0; }

1
$ musl-gcc -shared -fPIC greet.c -o libgreet.so
2
$ musl-gcc main.c -L. -lgreet -o prog

F，打开 -Wall -Wextra 编译：

1
// limit.c
2
long long limit = 5000000000LL;

1
// main.c
2
#include <stdio.h>
3
extern int limit;
4
int main(void) { printf("limit = %d\n", limit); return 0; }

改坏。同一对文件，只改一边的写法，看结果怎么变。把本章开头 other.c 的 extern double x; 改成带初值的定义 double x = 1.0;，set_x 的函数体留空，main.c 不动。先预测这次在哪个时期出错，再用 GNU ld 和 ld.lld 各链接一次，读懂两条报错，并用 readelf -s 比较两个 .o 里 x 的大小一栏。最后把 other.c 修好：写成 extern int x;，函数里赋值 x = 1;，重新编译运行，确认 y 回到了 5。

退出状态还可以成为自动测试的输入：正常退出与信号终止要分开表达，再由测试驱动核对。进程测试记录各条命令的进程返回状态；Python 的 subprocess 用负信号编号表示信号终止，便于与正常退出区分。

答案

以下结果在本机 Linux 的独立临时目录实测；每个案例都应保留自己的输入与产物，避免同名文件互相覆盖。

1
$ readelf -hW prog | grep Entry
2
  Entry point address:               0x40109e
3
$ nm prog | grep -E " _start$| _start_c$| main$"
4
000000000040109e T _start
5
00000000004010c0 T _start_c
6
0000000000401070 T main

1
$ readelf -lW prog | grep -E "^   03"
2
   03     .init_array .fini_array .data.rel.ro .got .got.plt .data .bss
3
$ readelf -SW prog | grep -E "init_array|fini_array|data|bss"
4
  [ 4] .rodata           PROGBITS        0000000000406000 006000 000c7a 00   A  0   0 32
5
  [ 6] .init_array       INIT_ARRAY      0000000000407fc0 006fc0 000008 08  WA  0   0  8
6
  [ 7] .fini_array       FINI_ARRAY      0000000000407fc8 006fc8 000008 08  WA  0   0  8
7
  [ 8] .data.rel.ro      PROGBITS        0000000000407fd0 006fd0 000010 00  WA  0   0  8
8
  [11] .data             PROGBITS        0000000000408000 007000 000110 00  WA  0   0 32
9
  [12] .bss              NOBITS          0000000000408120 007110 000698 00  WA  0   0 32

1
$ nm main.o
2
0000000000000000 T main
3
                 U printf
4
                 U set_x
5
0000000000000000 D x
6
0000000000000004 D y
7
$ nm other.o
8
0000000000000000 r .LC0
9
0000000000000000 T set_x
10
                 U x
11
$ readelf -sW other.o | grep -E " x$"
12
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND x

1
$ musl-gcc -O2 -Wall -Wextra -static table.c use.c -o arr
2
$ ./arr
3
$ echo $?
4
139

1
$ objdump -dr --no-show-raw-insn use.o
2
   8:	mov    0x0(%rip),%rax        # f <main+0xf>
3
			b: R_X86_64_PC32	table-0x4
4
  ...
5
  16:	mov    0x4(%rax),%esi

1
$ musl-gcc -static main.c -o prog
2
main.c: In function 'main':
3
main.c:3:33: error: implicit declaration of function 'squre'; did you mean 'square'? [-Wimplicit-function-declaration]

1
$ musl-gcc -c a.c && musl-gcc -c main.c
2
$ musl-gcc -static a.o main.o -o prog
3
ld: main.o:(.bss+0x0): multiple definition of `count'; a.o:(.bss+0x0): first defined here
4
collect2: error: ld returned 1 exit status

1
$ musl-gcc -c util.c && musl-gcc -c main.c
2
$ musl-gcc -static util.o main.o -o prog
3
ld: main.o: in function `main':
4
main.c:(.text+0xe): undefined reference to `helper'
5
collect2: error: ld returned 1 exit status
6
$ nm util.o
7
0000000000000000 t helper
8
0000000000000013 T twice

1
scale.c:3:6: error: conflicting types for 'scale'; have 'long int(long int)'
2
    3 | long scale(long v) { return v * 10; }
3
      |      ^~~~~
4
In file included from scale.c:2:
5
scale.h:2:5: note: previous declaration of 'scale' with type 'int(int)'

1
$ ./prog
2
Error loading shared library libgreet.so: No such file or directory (needed by ./prog)
3
Error relocating ./prog: greet: symbol not found
4
$ echo $?
5
127

1
$ ./prog
2
limit = 705032704

1
$ musl-gcc -O2 -Wall -Wextra -c main.c && musl-gcc -O2 -Wall -Wextra -c other.c
2
$ musl-gcc -static main.o other.o -o prog
3
ld: other.o:(.data+0x0): multiple definition of `x'; main.o:(.data+0x0): first defined here
4
collect2: error: ld returned 1 exit status
5
$ ld.lld -static main.o other.o -o /dev/null
6
ld.lld: error: duplicate symbol: x
7
>>> defined at main.c
8
>>>            main.o:(x)
9
>>> defined at other.c
10
>>>            other.o:(.data+0x0)
11
$ readelf -sW main.o | grep -E " x$"
12
     7: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    2 x
13
$ readelf -sW other.o | grep -E " x$"
14
     4: 0000000000000000     8 OBJECT  GLOBAL DEFAULT    2 x

1
$ cat other.c
2
extern int x;
3

4
void set_x(void) {
5
    x = 1;
6
}
7
$ musl-gcc -O2 -Wall -Wextra -c other.c
8
$ musl-gcc -static main.o other.o -o prog
9
$ ./prog
10
x = 1, y = 5

参考

• 开篇类型不匹配例子的来源：CMU 15-213，Fall 2026，《Linking》，PDF 第 22 页，Linker Puzzles。原题的一侧定义两个 int，另一侧写 double x;；本文将后一侧改成 extern double x;，避免 GCC 默认 -fno-common 时先触发重复定义，另调换了变量的源码顺序以观察文中 GCC 配置下的相邻覆盖。具体输出取决于产物，不能视为 C 语言保证。

• C 类型兼容规则：WG14 N1570，§6.2.7；链接期优化的类型诊断：GCC，-flto。

• MIT 6.035 Computer Language Engineering 第一讲：OCW Spring 2010

• MIT 6.828 JOS Lab 1（链接地址与加载地址）：Lab 1

• ELF 通用规范：gABI；x86-64 psABI

• GCC 10 移植说明（-fno-common）、GCC 14 移植说明（隐式函数声明）

• glibc 2.41 NEWS（dlopen 与可执行栈）

• musl libc