gcc符号表生成机制
符号表生成机制
我们以C语言的编译链接过程为例，详细讲解符号表（Symbol Table）的流程，涵盖编译和链接两个阶段。理解符号表是理解链接器如何解决符号引用（如函数、变量）的关键。
符号表分为两种：
- 目标文件（.o文件）中的符号表：由编译器生成，记录该文件内定义和引用的符号。
- 可执行文件或共享库中的符号表：由链接器生成，包含所有合并后的符号信息。
流程分为四个阶段：预处理、编译、汇编、链接。符号表主要在编译（生成汇编代码）和汇编（生成目标文件）阶段创建，在链接阶段被合并和解析。
1. 第一步：编译阶段（生成目标文件）
当我们编译一个源文件（如main.c）时：
gcc -c main.c -o main.o
编译器（如GCC）会进行以下操作：
- 语法分析、语义分析、中间代码生成、优化等。
- 生成汇编代码（main.s）。
- 汇编器将汇编代码翻译成机器指令（目标文件main.o）。
目标文件（main.o）的组成（以ELF格式为例）：
| 名称 | 作用 |
|---|---|
| .text段 | 存放代码（函数体）。 |
| .data段 | 存放已初始化的全局变量。 |
| .bss段 | 存放未初始化的全局变量（预留位置，不占磁盘空间）。 |
| .symtab | 符号表，记录本文件中定义和引用的符号信息。 |
符号表包含以下信息：
| 名称 | 作用 |
|---|---|
| 符号名（name） | 符号的唯一标识 |
| 符号值（value） | 对于函数和变量，表示其在相应段内的偏移地址（暂时，在链接前是0或相对偏移）。 |
| 大小（size） | |
| 类型（type） | 例如数据（变量）、函数、未定义等。 |
| 绑定信息（binding） | 全局（global）或局部（local）。 |
| 所在段（section） | 符号属于哪个段（text/data/bss），未定义的符号标记为UND。 |
例如，假设main.c中有如下代码：
extern int external_var; // 声明外部变量
int global_var = 10; // 全局变量，初始化，位于.data段
static int static_var; // 静态变量，未初始化，位于.bss段，且是local符号
void external_func(); // 声明外部函数int main() {
static_var = 1;
external_func();
return 0;
}
那么main.o的符号表中会有以下重要条目：
- global_var：类型为数据（object），在.data段，全局（global），value为0（待重定位）。
- static_var：类型为数据，在.bss段，局部（local），value为0。
- main：类型为函数（FUNC），在.text段，全局（global），value为0。
- external_var：类型为未定义（UND），全局（global）。
- external_func：类型为未定义（UND），全局（global）。
2. 第二步：链接阶段
当我们链接多个目标文件（例如还有func.o）生成可执行文件时：
gcc main.o func.o -o program
链接器（ld）的工作：
- 合并所有目标文件中的段（.text合并到.text，.data合并到.data等）。
- 符号解析：将所有目标文件的符号表合并为一个全局符号表，并解决符号引用。
符号解析过程：
- 链接器扫描所有目标文件，构建一个全局符号表。
- 对于每个未定义的符号，在全局符号表中查找是否有定义。
- 如果找到，则将引用指向该定义（在合并段中的地址）。
- 如果找不到，则报错：undefined reference to …。
例如，假设func.c中有：
int external_var = 100; // 定义external_var
void external_func() { // 定义external_func
}
则func.o的符号表中有：
- external_var：全局，定义在.data段。
- external_func：全局，定义在.text段。
链接器在合并时会：
将main.o中未定义的external_var和external_func解析到func.o中的定义。
同时，在合并段后，重新计算每个符号在最终可执行文件中的地址（即重定位）。
3. 第三步：重定位
链接器在完成符号解析后，还要修改代码段和数据段中对这些符号的引用地址（因为在合并段后，符号的地址发生了变化）。这一步由重定位表（.rel.text, .rel.data）指导完成。
重定位表（在目标文件中）记录了哪些位置需要重定位（即引用了外部符号的位置）。例如，在main.o中，调用external_func()的汇编指令中有一个占位符（地址为0）。链接器根据重定位表将该位置修改为external_func在最终可执行文件中的实际地址。
4. 第四步：生成可执行文件
链接器输出一个可执行文件（如ELF格式），其中包含：
- 所有段（.text, .data等）的合并内容。
- 符号表（通常可执行文件中的符号表可以被去除以减小体积，但若使用-g选项则保留）。
- 其他信息（重定位信息在可执行文件中不再需要，因为地址已固定，但动态链接信息除外）。
动态链接的符号解析与静态链接不同：
- 静态链接在链接阶段完全解析符号（ld直接解析了）。
- 动态链接在运行时由动态链接器（ld-linux.so）完成解析。
例如，如果我们在程序中使用了动态库（如libc.so）中的函数，在链接阶段，链接器只记录该函数在动态库中的符号名，并不解析具体地址。在可执行文件中，这些符号被标记为动态符号（在.dynsym节中），并且需要重定位表（.rel.plt, .rel.dyn）在运行时进行重定位。
5. 总结：
符号表的流程：
- 编译阶段：每个源文件编译成目标文件，生成局部符号表。
- 链接阶段：
- 合并所有目标文件的段。
- 合并符号表，进行符号解析（将未定义的符号绑定到定义的地方）。
- 重定位：根据新的段布局修改符号引用的地址（利用重定位表）。
- 输出可执行文件或共享库。
通过这个流程，链接器确保了程序中的所有符号引用都有唯一的定义，并位于正确的地址。
符号检查工具
# 查看目标文件符号
nm target.o# 详细符号信息
readelf -s target.o# 检查未定义符号
nm -u target.o# 显示动态符号表
readelf --dyn-syms program# 查看符号版本
objdump -T libc.so.6 | grep memcpy# 详细链接日志
ld --verbose# 跟踪链接过程
LD_DEBUG=all ./program# 重定位表检查
readelf -r program.o| 场景 | 示例错误信息 | 原因 |
|---|---|---|
| 函数未定义 | undefined reference to ‘func()’ | 函数声明存在，但无实现代码 |
| 函数签名不匹配 | undefined reference to ‘func(int)’ | 声明与定义的参数类型/数量不一致 |
| 库文件未链接 | unresolved external symbol | 依赖的静态库未加入链接命令 |
| C/C++ 混合编程未处理 | ?func@@YAHHH@Z（名称修饰不一致） | 未用 extern “C” 声明 C 函数 |