11、符号与符号表：全局符号、局部符号、强符号与弱符号

说到链接，绕不开一个核心概念——符号。

说白了，符号就是变量名、函数名这些标识符在编译器和链接器眼中的“身份证”。每个目标文件里都有一张符号表，记录着这个文件定义了哪些符号、引用了哪些符号。链接器就是靠这张表，把分散在不同文件里的代码拼到一起。

符号的本质

一个符号，在编译器的视角里，其实就是一个地址的别名。你写了个全局变量 int g_val;，编译器在生成目标文件时，就会在符号表里记一笔：g_val 这个符号，对应某个偏移地址。链接器拿到所有目标文件后，会把同名的符号合并，最终确定它在内存里的绝对地址。

我刚开始做嵌入式开发时，遇到过一个问题：两个.c文件里定义了同名的全局变量，结果程序跑起来后数据总是不对。查了半天，才发现是符号冲突了。嗯，从那以后我对符号表就格外上心。

全局符号 vs 局部符号

先看一个简单的分类：

符号类型 作用域 示例 符号表标记
全局符号 整个程序可见 int global_var;、void func() GLOBAL
局部符号 仅当前文件可见 static int local_var;、static void helper() LOCAL

全局符号可以被其他目标文件引用，局部符号则不行。你想想看，static 关键字的作用，其实就是把符号的作用域限制在文件内部，避免污染全局命名空间。

举个例子：

// file1.c
int global = 42;          // 全局符号
static int local = 10;    // 局部符号

void foo() {              // 全局符号
    // ...
}

// file2.c
extern int global;        // 引用全局符号
// extern int local;      // 错误！local 是局部符号，不可见

我在项目中见过有人滥用全局变量，结果不同模块之间互相覆盖数据，调试起来非常痛苦。我的建议是：能用 static 就用 static，把符号的可见性降到最低，这是最基本的模块化设计原则。

强符号 vs 弱符号

这个分类就更有意思了。C语言里，符号除了有作用域，还有“强度”之分。

  • 强符号：函数名、已初始化的全局变量名。比如 int x = 5;、void func() {}。
  • 弱符号：未初始化的全局变量名。比如 int y;（注意，没有 extern 修饰）。

你可能会问：为什么要有强弱之分？

原因很简单：链接器在处理多个目标文件时，如果遇到同名的符号，需要一套规则来决定用哪个。这套规则就是：

  1. 强符号不能重复定义。两个文件里都定义了 int x = 5;，链接器直接报错。
  2. 一个强符号可以覆盖多个弱符号。如果 file1.c 定义了 int x = 5;（强），file2.c 定义了 int x;（弱），链接器会选择强符号。
  3. 多个弱符号：如果全是弱符号，链接器会随机选一个（通常是占用空间最大的那个）。

我曾经在一个大型项目中，遇到过一个诡异的bug：某个全局变量在A模块里初始化为0，在B模块里也定义了一次（未初始化），结果程序运行时，A模块写入的值总是被B模块覆盖。查到最后，发现B模块的变量定义是弱符号，链接器把两个符号合并了，导致内存重叠。嗯，从那以后我写全局变量一定会加 extern 声明，避免这种隐晦的错误。

⚠️ 避坑指南
我曾经在调试一个多线程程序时，发现某个全局变量在不同线程里值不一致。最后定位到：两个.c文件都定义了同名的全局数组，一个初始化了，一个没初始化。链接器把它们合并了，但数组长度不同，导致内存越界。所以，永远不要依赖弱符号的默认行为，显式初始化或使用 extern 才是正道。

符号表的结构

每个目标文件（.o 文件）里都有一张符号表。你可以用 nm 命令查看：

$ nm file.o
00000000 T global_func
00000004 D global_init_var
00000008 C global_uninit_var
0000000c d local_static_var
         U printf

字母的含义：

  • T：全局函数（强符号）
  • D：已初始化的全局变量（强符号）
  • C：未初始化的全局变量（弱符号）
  • d：局部静态变量（局部符号）
  • U：未定义符号（需要从其他目标文件导入）

你看，符号表里不仅记录了符号的名字和地址，还记录了它的类型和强度。链接器就是根据这些信息，决定如何合并符号。

符号解析的流程

链接器处理符号时，大致分三步：

  1. 收集所有目标文件的符号表，建立全局符号列表。
  2. 解析未定义符号：对于每个 U 类型的符号，在所有已定义符号中查找匹配项。如果找不到，报“未定义引用”错误。
  3. 处理多重定义：按照强弱规则，决定最终使用哪个符号。

这里有个细节：链接器是按顺序处理目标文件的。如果你把库文件放在前面，可能会导致符号解析失败。我建议把库文件放在命令行的最后，比如：

gcc main.o utils.o -lm

而不是：

gcc -lm main.o utils.o   // 可能出问题
💡 小技巧
如果你不确定某个符号是强是弱，可以用 nm -a 查看所有符号，或者用 readelf -s 查看 ELF 格式的符号表。我个人习惯在写库代码时，把所有内部函数都声明为 static，这样既避免了符号冲突，也减少了链接器的工作量。

符号与链接的底层逻辑

为了让你更直观地理解符号在链接过程中的流转，我画了一张图：

file1.o T main D g_val = 5 U printf file2.o T helper C g_val d local_static libc.a T printf ... 链接器 符号解析 + 重定位 a.out g_val = 5 (强符号胜出)

这张图展示了一个典型的链接过程。file1.o 定义了强符号 g_val = 5，file2.o 定义了弱符号 g_val（未初始化）。链接器按照强弱规则，最终选择了 file1.o 中的强符号。同时，file1.o 引用的 printf 从 libc.a 中解析得到。

🔑 核心要点
  • 全局符号用 extern 声明，局部符号用 static 限制。
  • 强符号（已初始化全局变量、函数）不能重复定义。
  • 弱符号（未初始化全局变量）可以被强符号覆盖。
  • 多个弱符号会导致未定义行为，尽量避免。
  • 用 nm 或 readelf 查看符号表，是调试链接问题的利器。

符号表是链接器工作的基础。理解了强弱符号的规则，你就能解释很多看似“奇怪”的编译链接行为。比如为什么两个文件里定义了同名的全局变量，有时候报错，有时候不报错——答案就在符号的强度里。

嗯，这一节的内容就到这里。记住：写代码时对符号多一分敬畏，调试时就少一分痛苦。

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

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