GDB 源码分析系列文章三：调试信息的处理、符号表的创建和使用_gdb 符号表

系列文章：

GDB 源码分析系列文章一：ptrace 系统调用和事件循环（Event Loop）
GDB 源码分析系列文章二：gdb 主流程 Event Loop 事件处理逻辑详解
GDB 源码分析系列文章三：调试信息的处理、符号表的创建和使用
GDB 源码分析系列文章四：gdb 事件处理异步模式分析 ---- 以 ctrl-c 信号为例
GDB 源码分析系列文章五：动态库延迟断点实现机制

gdb 之所以能够进行源码级调试，本质上是编译的过程保存了源码到目标程序之间的映射关系，包括行号、地址等映射关系。gdb 在调试程序时，会对调试信息和符号表进行加工处理，得到 gdb 内部的符号表，gdb 依靠符号表完成一些列调试任务。

调试信息和符号表简介

这里说的调试信息指的是 debug_* 相关信息，符号表是指 symtab 和 dynsym。gdb 对这两种信息进行解析和加工，得到的信息在 gdb 内部统称为符号表。

调试信息

调试信息需要带上 -g 编译选项才能产生。关于调试信息在我之前的博客中有一篇引导性的介绍 调试信息（debugging information）——解析DWARF文件 这里只简单列举下各个 section。

使用 readelf -S xx.out 得到可执行文件各个 section 的列表：

There are 37 section headers, starting at offset 0x99d8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000000318  00000318
       000000000000001c  0000000000000000   A       0     0     1
  [ 2] .note.gnu.propert NOTE             0000000000000338  00000338
       0000000000000020  0000000000000000   A       0     0     8
  [ 3] .note.gnu.build-i NOTE             0000000000000358  00000358
       0000000000000024  0000000000000000   A       0     0     4
  [ 4] .note.ABI-tag     NOTE             000000000000037c  0000037c
       0000000000000020  0000000000000000   A       0     0     4
  [ 5] .gnu.hash         GNU_HASH         00000000000003a0  000003a0
       0000000000000024  0000000000000000   A       6     0     8
  [ 6] .dynsym           DYNSYM           00000000000003c8  000003c8
       00000000000000a8  0000000000000018   A       7     1     8
  [ 7] .dynstr           STRTAB           0000000000000470  00000470
       0000000000000084  0000000000000000   A       0     0     1
  [ 8] .gnu.version      VERSYM           00000000000004f4  000004f4
       000000000000000e  0000000000000002   A       6     0     2
  [ 9] .gnu.version_r    VERNEED          0000000000000508  00000508
       0000000000000020  0000000000000000   A       7     1     8
  [10] .rela.dyn         RELA             0000000000000528  00000528
       00000000000000c0  0000000000000018   A       6     0     8
  [11] .rela.plt         RELA             00000000000005e8  000005e8
       0000000000000018  0000000000000018  AI       6    24     8
  [12] .init             PROGBITS         0000000000001000  00001000
       000000000000001b  0000000000000000  AX       0     0     4
  [13] .plt              PROGBITS         0000000000001020  00001020
       0000000000000020  0000000000000010  AX       0     0     16
  [14] .plt.got          PROGBITS         0000000000001040  00001040
       0000000000000010  0000000000000010  AX       0     0     16
  [15] .plt.sec          PROGBITS         0000000000001050  00001050
       0000000000000010  0000000000000010  AX       0     0     16
  [16] .text             PROGBITS         0000000000001060  00001060
       00000000000001d5  0000000000000000  AX       0     0     16
  [17] .fini             PROGBITS         0000000000001238  00001238
       000000000000000d  0000000000000000  AX       0     0     4
  [18] .rodata           PROGBITS         0000000000002000  00002000
       000000000000000c  0000000000000000   A       0     0     4
  [19] .eh_frame_hdr     PROGBITS         000000000000200c  0000200c
       000000000000004c  0000000000000000   A       0     0     4
  [20] .eh_frame         PROGBITS         0000000000002058  00002058
       0000000000000128  0000000000000000   A       0     0     8
  [21] .init_array       INIT_ARRAY       0000000000003db8  00002db8
       0000000000000008  0000000000000008  WA       0     0     8
  [22] .fini_array       FINI_ARRAY       0000000000003dc0  00002dc0
       0000000000000008  0000000000000008  WA       0     0     8
  [23] .dynamic          DYNAMIC          0000000000003dc8  00002dc8
       00000000000001f0  0000000000000010  WA       7     0     8
  [24] .got              PROGBITS         0000000000003fb8  00002fb8
       0000000000000048  0000000000000008  WA       0     0     8
  [25] .data             PROGBITS         0000000000004000  00003000
       0000000000000014  0000000000000000  WA       0     0     8
  [26] .bss              NOBITS           0000000000004014  00003014
       0000000000000004  0000000000000000  WA       0     0     1
  [27] .comment          PROGBITS         0000000000000000  00003014
       000000000000002b  0000000000000001  MS       0     0     1
  [28] .debug_aranges    PROGBITS         0000000000000000  0000303f
       0000000000000030  0000000000000000           0     0     1
  [29] .debug_info       PROGBITS         0000000000000000  0000306f
       000000000000037f  0000000000000000           0     0     1
  [30] .debug_abbrev     PROGBITS         0000000000000000  000033ee
       0000000000000122  0000000000000000           0     0     1
  [31] .debug_line       PROGBITS         0000000000000000  00003510
       0000000000000266  0000000000000000           0     0     1
  [32] .debug_str        PROGBITS         0000000000000000  00003776
       00000000000047a7  0000000000000001  MS       0     0     1
  [33] .debug_macro      PROGBITS         0000000000000000  00007f1d
       000000000000106a  0000000000000000           0     0     1
  [34] .symtab           SYMTAB           0000000000000000  00008f88
       00000000000006d8  0000000000000018          35    52     8
  [35] .strtab           STRTAB           0000000000000000  00009660
       000000000000020c  0000000000000000           0     0     1
  [36] .shstrtab         STRTAB           0000000000000000  0000986c
       0000000000000167  0000000000000000  
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  l (large), p (processor specific)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

其中 .debug 打头的就是调试信息了。

符号表

其实符号表包括 symtab 和 dynsym 两种。在没有 -g 编译也会产生，在重定位过程中需要处理。

• symtab 包括两种类型符号：全局符号和本地静态符号。
• dynsym 仅仅包加载动态库所需要的符号。

其实，symtab 是包含了 dynsym，也就是说 dynsym 是 symtab 的子集。那为什么还要保存重复的 dynsym 呢？当对目标程序进行 strip 时 strip xx.out ，symtab 将会被去除，但是 dynsym 还在，可以保证动态加载可以正常工作。因此，gdb 在解析符号表时候，只需要读取 symtab 即可。

调试信息的处理和符号表的创建

gdb 读取调试信息和符号表，在 gdb 使用符号表来记录， gdb 内部存在 3 种符号表。

1. minimal symbol table：最小符号表。直接读取 ELF 文件中 .symtab 的 section。也即链接过程中使用到的符号。最小符号表 “better than nothing” 。最小符号表至少可以满足你通过函数名打断点。
2. partial symbol table：部分符号表。在 minimal symbol table 基础上初步分析调试信息（.debug_info section），得到部分符号的部分信息，可以满足一定的调试要求。并且部分符号表记录了读取完整符号表的函数指针，可以在部分符号表的基础上读取完整符号表。
3. full symbol table：完整符号表。记录了完整的调试信息，占用内存大。gdb 首先是建立部分符号表，只在必要的时候才会建立完整的符号表。

最小符号表

最小符号表是直接读取 ELF 文件的 .symtab section 得到。

最小符号表数据结构简介

在看 minimal_symbol 之前，先看下 general_symbol_info。general_symbol_info 是在所有 3 种符号（minimal_symbol，partial_symbol 和 (full) symbol）都共有的成员。

general_symbol_info 主要成员如下（详见 gdb/symtab.h）：

minimal_symbol 主要成员如下（详见 gdb/symtab.h）：

minimal_symbol 最后存储在 objfile 的 per-bfd 的存储空间，形成 minimal symbol table。

最小符号表创建流程

read_symbols
  elf_symfile_read
    elf_read_minimal_symbols
      elf_symtab_read
      install_minimal_symbols

elf_symfile_read 调用 elf_read_minimal_symbols 读取和建立最小符号表。

elf_read_minimal_symbols 首先通过 bfd 库得到 .symtab section 的大小和符号个数。然后调用 elf_symtab_read 函数读取符号表。最后调用 install_minimal_symbols 安装符号表。

install_minimal_symbols 会对符号表进行排序、去重、压缩后存放在 objfile->per_bfd->msymbols 中，再给 minimal symblos 建立 hash table，用于对 minimal symbols 进行索引。

此外，符号表除了 dwarf 格式，还有其他格式，例如 stab 格式。符号表的建立流程中还有很多兼容性处理，这里不再赘述。

部分符号表

部分符号表是在最小符号表的基础上，尝试读取 dwarf 的调试信息，形成相对比较完整的符号表。

部分符号表数据结构简介

partial_symbol 成员如下（详见 gdb/psympriv.h）：

partial_symbol 以一定的规则组合形成 partial_symtab，一个源文件对应一个 partial_symtab，一个 objfile 中所有 partial_symtab 形成一个链表。

partial_symtab 主要成员如下（详见 gdb/psympriv.h）：

每个源文件还没有完全读入，会先形成部分符号表。其中包含有关特定文件的调试符号在可执行文件中的位置的信息，以及位于该文件中的全局符号的名称列表。它们链接形成部分符号列表，即使完整符号表读入后，它们依然保留。

部分符号表创建流程

read_symbols
  require_partial_symbols
    read_psyms
      dwarf2_build_psymtabs
        dwarf2_build_psymtabs_hard

建立最小符号表后，随即调用到 dwarf2_build_psymtabs_hard，在 dwarf2_build_psymtabs_hard 中处理 .debug_info 和 .debug_abbrev section 建立部分符号表 。

dwarf2_build_psymtabs_hard
  dwarf2_read_section
  create_all_comp_units
  process_psymtab_comp_unit
    init_cutu_and_read_dies
    process_psymtab_comp_unit_reader
      create_partial_symtab
      load_partial_dies
      scan_partial_symbols
      dwarf2_build_include_psymtabs

dwarf2_build_psymtabs_hard 首先调用 dwarf2_read_section 将 .debug_info section 读入。然后调用 create_all_comp_units 找到每个 compile unit （cu），记录 cu 个数，然后依次读取 cu 的 offset、length 等信息。最后调用 process_psymtab_comp_unit 处理每个 cu 的信息。

init_cutu_and_read_dies 首先读取 .debug_info section 的 Abbrev offset ，该 offset 是本 cu 在 .debug_abbrev 中的偏移。然后读取该 cu 的 .debug_abbrev section。接着根据 abbrev 读取 comiple unit 的 DIE。

在读取 cu 信息后，调用process_psymtab_comp_unit_reader 处理该 cu 的符号信息。由于一个 cu 对应一个 partial symtab（pst），根据文件名、路径、完整符号表调用函数等信息通过 create_partial_symtab 函数建立符号表，并添加到 objfile->psymtabs 中，并设置 pst 的 globals_offset 和 static_offset 等信息。

建立 pst 后，调用 load_partial_dies 将感兴趣的 dies 读入，这里只读入本文件全局或者静态变量相关的 die。比如 DW_TAG_subprogram 是代表一个函数的 die，DW_TAG_variable 代表变量的 die。
的
scan_partial_symbols 解析这些 dies，不同 die 有不同的处理函数，得到 global symbols 和 static symbols，并存放到 objfile->global_psymbols 和 objfile->static_psymbols 中，得到该文件的全局符号和静态符号信息，但这里不包括局部符号。这里顺便说下，对于函数符号，psym->ginfo.value.address 存放的是函数首地址，对于全局或者静态变量，存放的是变量地址。

最后，还需要调用 dwarf2_build_include_psymtabs 处理本文件包含的头文件的 pst。这里只会为本文件实际用到的头文件建立 pst（例如，你可能 include 了一个不需要的头文件，那则没必要为它建立 pst）。这就需要分析 .debug_line 的信息了。.debug_line 中的行信息也是以 cu 为单位存放的。逐行解析.debug_line 中的 opcode，有的 opcode 会改变 file 寄存器，并且与当前文件 file 寄存器值不一样，则需要为该 include file 创建 pst， 并加入到 objfile->psymtabs 中，并记录 include file 的 dependencies 为本文件 pst。

至此，psts 建立完成。

完整符号表

如果 gdb 调试过程中需要的符号信息，超出了 pst 的范围，则需要根据 pst 的函数指针 read_symtab 读取完整符号表。

完整符号表数据结构简介

完整符号表的符号定义在 gdb/symtab.h 中。struct symbol 主要成员如下：

struct symtab 主要成员如下：

另外，完整符号表定义了 struct pending *file_symbols、pending *global_symbols 和 pending *local_symbols 等信息分别记录 static、global 和 local 符号信息。详见 gdb/buildsym.h 。

完整符号表创建流程

dwarf2_read_symtab
  psymtab_to_symtab_1
   dw2_do_instantiate_symtab
    load_cu
    process_queue
     process_full_comp_unit
      process_die
        read_file_scope
        read_func_scope
        process_structure_scope
        new_symbol
      end_symtab_get_static_block
      end_symtab_from_static_block
        end_symtab_with_blockvector

dwarf2_read_symtab 首先调用 psymtab_to_symtab_1 包含依赖文件在内的所有文件的 符号表。 psymtab_to_symtab_1 再调用 load_cu 读取 cu，加入到 queue 中，然后调用 process_queue->process_full_comp_unit->process_die 处理每个 die，建立完整符号表。

process_die 根据不同 die 进入不同的分发函数进行处理。比如 read_func_scope 函数：将局部变量放到 local_symbols、file_static 变量符号放到 static_symbols、global 符号放入到 global_symbols。函数创建 block，block 的 startaddr 和 endaddr 对应函数的 pc 地址范围，将局部符号添加到 block->dict 中，并将函数的 symbol 和 block 绑定，再将该block 放入pending_blocks 中。

最后，end_symtab_with_blockvector 构建 static_blocks，将 file_symbols 添加到它的 dict 中。构建 global_blocks，将 global_symbols 添加到它的 dict 中。最后将 static_blocks 、globla_blocks 和 pending_blocks 组成 blockvector。最后放到 symtab 的 compunit_symtab 中。

符号表的使用

使用符号表的接口为 lookup_symbol。根据当前 pc，找到当前 block，在该 block 的 dict 中查找所需的符号（根据符号名），若找到，则返回。否则在 static_block 中 dict 查找，若找到，则返回。若还找不到，说明不在当前 cu 中，接着调用 lookup_global_symbol。在 lookup_global_symbol->…->lookup_symbol_in_objfile 中，先调用 lookup_symbol_in_objfile_symtabs，若找到，则返回。否则，这个时候需要遍历 psts，在 obifile->global_symbols 查找，找到对应的 pst，进入完整符号表的构建。这里也可以看到，只在需要的时候才会建立完整的符号表。在完整符号表建立后，上述查找符号表的过程中就一定能够找到所需的符号了。