3. 符号表与DWARF：ELF文件格式解析、DWARF调试信息格式、符号表加载机制
调试器是怎么知道你的变量名叫什么？又是怎么找到源代码对应哪一行机器码的？
嗯，这背后就是符号表和DWARF调试信息在起作用。我当年刚接触GDB时，以为调试信息就是简单的“变量名→地址”映射表。后来被一个莫名其妙的断点失效问题折磨了两天，才老老实实把ELF和DWARF啃了一遍。
3.1 ELF文件格式：不只是可执行文件
ELF（Executable and Linkable Format）是Linux下最常用的二进制格式。它不只是存放机器码，还包含了链接、加载、调试所需的一切元数据。
一个典型的ELF文件结构如下：
+-------------------+
| ELF Header | ← 文件头，描述架构、入口点、段表位置等
+-------------------+
| Program Headers | ← 段表，用于加载器（loader）将文件映射到内存
+-------------------+
| Section Headers | ← 节表，用于链接器和调试器
+-------------------+
| .text | ← 代码段
| .data | ← 已初始化全局变量
| .bss | ← 未初始化全局变量
| .symtab | ← 符号表
| .debug_* | ← DWARF调试信息
| ... |
+-------------------+我个人习惯用 readelf 来查看ELF结构。比如：
$ readelf -h a.out
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Machine: Advanced Micro Devices X86-64
Entry point address: 0x400430
Start of section headers: 6648 (bytes into file)
...这里有个关键点：节表（Section Headers）和段表（Program Headers）是两套不同的视图。节表面向链接器和调试器，段表面向加载器。你想想看，调试器需要知道每个节的起始地址和大小，而操作系统只需要知道哪些段要加载到内存、权限是什么。
核心概念：符号表是ELF中一个特殊的节（.symtab或.dynsym），它记录了符号名称和地址的对应关系。没有符号表，GDB就只能看到一堆裸地址。
3.2 符号表：调试器的“地图”
符号表说白了就是一个字典。键是函数名或变量名，值是地址或偏移量。
看一个简单的例子：
// test.c
int global_var = 42;
void func(int x) {
int local = x + 1;
}
int main() {
func(10);
return 0;
}编译后查看符号表：
$ gcc -g -o test test.c
$ nm test
00000000004004ed T func
0000000000601038 D global_var
0000000000400506 T main这里的 T 表示代码段中的全局符号，D 表示数据段中的符号。GDB就是靠这些信息把 main 映射到地址 0x400506 的。
我在项目中遇到过一个问题：strip掉符号表后，GDB还能用吗？答案是：部分能用。strip会移除.symtab，但不会动.debug_*节。所以函数名还能显示，但局部变量名就丢了。嗯，这就是为什么生产环境里经常用 strip --strip-debug 而不是 strip --strip-all。
避坑指南：我曾经在调试一个crash问题时，发现backtrace里全是问号。折腾了半天才发现是编译时加了 -s 选项，把符号表全干掉了。从那以后，我编译调试版本时一定会用 -g，并且绝不strip。
3.3 DWARF调试信息格式：符号表的“进阶版”
符号表只能告诉你“变量在哪个地址”。但调试器还需要知道更多：变量的类型是什么？结构体成员怎么偏移？源代码哪一行对应哪条指令？
这些信息，DWARF都能提供。
DWARF（Debugging With Attributed Record Formats）是一种复杂的调试信息格式。它用“调试信息条目”（DIE，Debugging Information Entry）来描述程序中的每个实体。
一个典型的DIE树结构如下：
编译单元 (DW_TAG_compile_unit)
├── 子程序 (DW_TAG_subprogram) ← main函数
│ ├── 形式参数 (DW_TAG_formal_parameter) ← argc
│ ├── 形式参数 (DW_TAG_formal_parameter) ← argv
│ └── 变量 (DW_TAG_variable) ← 局部变量
├── 基类型 (DW_TAG_base_type) ← int
└── 结构体类型 (DW_TAG_structure_type) ← 自定义结构体用 dwarfdump 可以查看这些信息：
$ dwarfdump test
DW_TAG_compile_unit
DW_AT_name "test.c"
DW_AT_language DW_LANG_C99
DW_AT_low_pc 0x400506
DW_AT_high_pc 0x400520
DW_TAG_subprogram
DW_AT_name "main"
DW_AT_low_pc 0x400506
DW_AT_high_pc 0x400520
DW_AT_type <0x...> (int)你可能会问：为什么GDB不用更简单的格式？
原因很简单：C/C++的类型系统太复杂了。想想看，一个函数指针、一个模板类、一个虚继承……这些信息用简单的符号表根本表达不了。DWARF用树形结构，可以精确描述任意复杂的类型。
关键点：DWARF的.debug_info节包含了完整的类型信息，而.debug_line节则提供了源代码行号到机器码地址的映射。GDB设置断点时，就是通过.debug_line找到对应地址的。
3.4 符号表加载机制：GDB是怎么工作的？
当你用GDB加载一个可执行文件时，背后发生了这些事情：
- 读取ELF头：GDB先解析ELF头，找到节表的位置。
- 加载符号表：GDB读取.symtab或.dynsym节，把符号名和地址存入内部哈希表。
- 解析DWARF：GDB遍历.debug_info节，构建类型系统和行号映射。
- 延迟加载：对于共享库，GDB会在运行时动态加载它们的符号表。
这里有个细节：GDB不会一次性加载所有DWARF信息。因为一个大型项目的调试信息可能有几百MB，全加载到内存里太浪费了。GDB采用“按需加载”策略——只有当你展开某个变量或设置某个断点时，才去解析对应的DIE。
我曾经调试过一个Qt项目，光.debug_info就有200多MB。第一次加载时GDB卡了十几秒，我差点以为它死掉了。后来才知道可以用 set dwarf-max-cache-age 0 来限制缓存大小。
注意事项：如果你用 -O2 或更高优化级别编译，DWARF信息可能会不准确。比如变量被优化掉了，或者行号对应关系错乱。我建议调试时用 -O0 -g，虽然程序跑得慢，但调试体验好得多。
3.5 实战：用GDB查看符号和DWARF
光说不练假把式。我们实际操作一下：
$ gdb ./test
(gdb) info functions ← 查看所有函数符号
All functions matching regular expression "":
File test.c:
void func(int);
int main();
(gdb) info variables ← 查看所有全局变量
All variables matching regular expression "":
File test.c:
int global_var;
(gdb) info line main ← 查看main函数的行号信息
Line 8 of "test.c" starts at address 0x400506 <main>
and ends at 0x400520 <main+26>.看到了吗？GDB把符号表和DWARF信息整合在一起，给你一个统一的视图。当你输入 print global_var 时，GDB先查符号表找到地址 0x601038，再查DWARF知道它是 int 类型，然后读取4个字节并显示出来。
嗯，整个过程说起来简单，但GDB内部做了大量工作。尤其是处理C++的命名修饰（name mangling）时，GDB需要把 _Z3funci 还原成 func(int)，这全靠DWARF里的类型信息。
小技巧：如果你怀疑GDB的符号表加载有问题，可以用 maintenance print symbols 命令打印GDB内部维护的符号表。这招我在排查“为什么GDB找不到某个变量”时屡试不爽。
3.6 本章小结
符号表和DWARF是GDB的“眼睛”。没有它们，GDB就是个盲人调试器，只能看裸地址和机器码。
- ELF文件：用节表和段表组织二进制内容，符号表是其中的一个节。
- 符号表：提供“名称→地址”的映射，简单但信息有限。
- DWARF：提供类型、行号、作用域等丰富信息，用树形结构组织。
- 加载机制：GDB按需加载，延迟解析，兼顾速度和内存。
说实话，DWARF的规范文档有几千页，我到现在也没完全看完。但作为嵌入式开发者，你不需要成为DWARF专家——只要理解它的设计思路，知道GDB怎么用它就够了。遇到问题时，能用 readelf 和 dwarfdump 定位问题，就已经超过90%的工程师了。
这张图展示了GDB从加载ELF到构建内部符号表的完整流程。你可以看到，符号表和DWARF是两条并行的信息流，最终在GDB内部合并成统一的调试视图。