gcc符号表生成机制

符号表生成机制

我们以C语言的编译链接过程为例，详细讲解符号表（Symbol Table）的流程，涵盖编译和链接两个阶段。理解符号表是理解链接器如何解决符号引用（如函数、变量）的关键。

符号表分为两种：

• 目标文件（.o文件）中的符号表：由编译器生成，记录该文件内定义和引用的符号。
• 可执行文件或共享库中的符号表：由链接器生成，包含所有合并后的符号信息。

流程分为四个阶段：预处理、编译、汇编、链接。符号表主要在编译（生成汇编代码）和汇编（生成目标文件）阶段创建，在链接阶段被合并和解析。

1. 第一步：编译阶段（生成目标文件）

当我们编译一个源文件（如main.c）时：

gcc -c main.c -o main.o

编译器（如GCC）会进行以下操作：

1. 语法分析、语义分析、中间代码生成、优化等。
2. 生成汇编代码（main.s）。
3. 汇编器将汇编代码翻译成机器指令（目标文件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）的工作：

1. 合并所有目标文件中的段（.text合并到.text，.data合并到.data等）。
2. 符号解析：将所有目标文件的符号表合并为一个全局符号表，并解决符号引用。

符号解析过程：

• 链接器扫描所有目标文件，构建一个全局符号表。
• 对于每个未定义的符号，在全局符号表中查找是否有定义。
• 如果找到，则将引用指向该定义（在合并段中的地址）。
• 如果找不到，则报错：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. 总结：

符号表的流程：

1. 编译阶段：每个源文件编译成目标文件，生成局部符号表。
2. 链接阶段：
   • 合并所有目标文件的段。
   • 合并符号表，进行符号解析（将未定义的符号绑定到定义的地方）。
   • 重定位：根据新的段布局修改符号引用的地址（利用重定位表）。
   • 输出可执行文件或共享库。

通过这个流程，链接器确保了程序中的所有符号引用都有唯一的定义，并位于正确的地址。

符号检查工具

# 查看目标文件符号
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 函数