如何在GDB中关联源代码

原文：How to point GDB to your sources
翻译：雁惊寒

如果你手头上有一个你自己或者别人开发的程序，但它有一些bug。或者你只是想知道这个程序是如何工作的。怎么办呢？你需要一个调试工具。

现在很少有人会直接对着汇编指令进行调试，通常情况下，大家都希望能对照着源代码进行调试。但是，你调试使用的主机，一般来说并不是构建程序的那台，因此你会看到如下这个令人沮丧的消息：

$ gdb -q python3.7
Reading symbols from python3.7...done.
(gdb) l
6   ./Programs/python.c: No such file or directory.

我经常会看到这些报错信息，并且对于调试程序来说，这也非常重要。所以，我认为我们需要详细了解一下GDB是如何在调试会话中显示源代码的。

调试信息

首先，我们从调试信息开始。调试信息是由编译器生成的存在于二进制文件中的特殊段，供调试器和其他相关的工具使用。

在GCC中，有一个著名的-g标志用于生成调试信息。大多数使用某种构建系统的项目都会在构建时默认包含或者通过一些标志来添加调试信息。

例如，在CPython中，你需要执行以下命令：

$ ./configure --with-pydebug
$ make -j

-with-pydebug会在调用GCC时添加-g选项。

这个-g选项会生成二进制的调试段，并插入到程序的二进制文件中。调试段通常采用DWARF格式。对于ELF二进制文件来说，调试段的名称一般都是像.debug_ *这样的，例如 .debug_info或者.debug_loc。这些调试段使得调试程序成为可能，可以这么说，它是汇编级别的指令与源代码之间的映射。

要查看程序是否包含调试符号，你可以使用objdump命令列出二进制文件的所有段：

$ objdump -h ./python

python:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .interp       0000001c  0000000000400238  0000000000400238  00000238  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  0000000000400254  0000000000400254  00000254  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
...
 25 .bss          00031f70  00000000008d9e00  00000000008d9e00  002d9dfe  2**5
                  ALLOC
 26 .comment      00000058  0000000000000000  0000000000000000  002d9dfe  2**0
                  CONTENTS, READONLY
 27 .debug_aranges 000017f0  0000000000000000  0000000000000000  002d9e56  2**0
                  CONTENTS, READONLY, DEBUGGING
 28 .debug_info   00377bac  0000000000000000  0000000000000000  002db646  2**0
                  CONTENTS, READONLY, DEBUGGING
 29 .debug_abbrev 0001fcd7  0000000000000000  0000000000000000  006531f2  2**0
                  CONTENTS, READONLY, DEBUGGING
 30 .debug_line   0008b441  0000000000000000  0000000000000000  00672ec9  2**0
                  CONTENTS, READONLY, DEBUGGING
 31 .debug_str    00031f18  0000000000000000  0000000000000000  006fe30a  2**0
                  CONTENTS, READONLY, DEBUGGING
 32 .debug_loc    0034190c  0000000000000000  0000000000000000  00730222  2**0
                  CONTENTS, READONLY, DEBUGGING
 33 .debug_ranges 00062e10  0000000000000000  0000000000000000  00a71b2e  2**0
                  CONTENTS, READONLY, DEBUGGING

或者使用readelf命令:

$ readelf -S ./python
There are 38 section headers, starting at offset 0xb41840:

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         0000000000400238  00000238  000000000000001c  0000000000000000   A       0     0     1

...

  [26] .bss              NOBITS           00000000008d9e00  002d9dfe
       0000000000031f70  0000000000000000  WA       0     0     32
  [27] .comment          PROGBITS         0000000000000000  002d9dfe
       0000000000000058  0000000000000001  MS       0     0     1
  [28] .debug_aranges    PROGBITS         0000000000000000  002d9e56
       00000000000017f0  0000000000000000           0     0     1
  [29] .debug_info       PROGBITS         0000000000000000  002db646
       0000000000377bac  0000000000000000           0     0     1
  [30] .debug_abbrev     PROGBITS         0000000000000000  006531f2
       000000000001fcd7  0000000000000000           0     0     1
  [31] .debug_line       PROGBITS         0000000000000000  00672ec9
       000000000008b441  0000000000000000           0     0     1
  [32] .debug_str        PROGBITS         0000000000000000  006fe30a
       0000000000031f18  0000000000000001  MS       0     0     1
  [33] .debug_loc        PROGBITS         0000000000000000  00730222
       000000000034190c  0000000000000000           0     0     1
  [34] .debug_ranges     PROGBITS         0000000000000000  00a71b2e
       0000000000062e10  0000000000000000           0     0     1
  [35] .shstrtab         STRTAB           0000000000000000  00b416d5
       0000000000000165  0000000000000000           0     0     1
  [36] .symtab           SYMTAB           0000000000000000  00ad4940
       000000000003f978  0000000000000018          37   8762     8
  [37] .strtab           STRTAB           0000000000000000  00b142b8
       000000000002d41d  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

在我们刚刚编译的Python程序中，我们可以看到.debug_ *段，因此它是包含调试信息的。

调试信息是DIE（调试信息条目）的一个集合。每个DIE都有一个标签，用来表示DIE的类型以及它的属性，就像变量的名称和行号一样。

GDB如何寻找源代码

为了寻找源代码，GDB会解析.debug_info段并查找所有带有DW_TAG_compile_unit标签的DIE。具有此标签的DIE有两个主要属性DW_AT_comp_dir（编译目录）和DW_AT_name（名称），这就是源代码的路径。把这两个属性结合起来就是某个特定编译单元（对象文件）对应的源文件的完整路径。

要解析调试信息，你仍然可以使用objdump命令:

$ objdump -g ./python | vim -

你可以看到这些解析出来的调试信息：

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x222d (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0xb6b): GNU C99 6.3.1 20161221 (Red Hat 6.3.1-1) -mtune=generic -march=x86-64 -g -Og -std=c99
    <10>   DW_AT_language    : 12   (ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x10ec): ./Programs/python.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x7a): /home/avd/dev/cpython
    <19>   DW_AT_low_pc      : 0x41d2f6
    <21>   DW_AT_high_pc     : 0x1b3
    <29>   DW_AT_stmt_list   : 0x0

GDB是这样读取的：地址从DW_AT_low_pc = 0×41d2f6到DW_AT_low_pc + DW_AT_high_pc = 0×41d2f6 + 0×1b3 = 0×41d4a9对应的源代码文件是位于/home/avd/dev/cpython路径下的./Programs/python.c文件，相当简单吧。

这是GDB向你显示源代码的整个过程：

解析.debug_info查找当前对象文件的DW_AT_name属性的DW_AT_comp_dir属性
按照路径DW_AT_comp_dir/DW_AT_name打开文件
显示文件的内容

如何告诉GDB源代码的位置

所以，要解决./Programs/python.c: No such file or directory.这个问题，我们必须在目标主机上存放源代码（复制或git clone过来），并执行以下任意一个操作：

重建源代码路径

你可以在目标主机上重建源代码路径，这样，GDB就能找到对应的源代码了。这是个愚蠢的办法，但是还是很有用的。

在我这个例子中，我执行了这个命令git clone https://github.com/python/cpython.git /home/avd/dev/cpython来检出所需的版本。

修改GDB源代码路径

你可以在调试会话中使用directory <dir>命令让GDB关联正确的源代码路径：

(gdb) list
6   ./Programs/python.c: No such file or directory.
(gdb) directory /usr/src/python
Source directories searched: /usr/src/python:$cdir:$cwd
(gdb) list
6   #ifdef __FreeBSD__
7   #include <fenv.h>
8   #endif
9   
10  #ifdef MS_WINDOWS
11  int
12  wmain(int argc, wchar_t **argv)
13  {
14      return Py_Main(argc, argv);
15  }

设置GDB路径替换规则

如果目录结构层次比较复杂，有时候添加源代码路径是不够的。在这种情况下，你可以使用set substitute-path命令来添加源路径的替换规则。

(gdb) list
6   ./Programs/python.c: No such file or directory.
(gdb) set substitute-path /home/avd/dev/cpython /usr/src/python
(gdb) list
6   #ifdef __FreeBSD__
7   #include <fenv.h>
8   #endif
9   
10  #ifdef MS_WINDOWS
11  int
12  wmain(int argc, wchar_t **argv)
13  {
14      return Py_Main(argc, argv);
15  }

把二进制文件移到源代码目录

你可以通过将二进制文件移动到源代码目录来改变GDB源代码路径。

mv python /home/user/sources/cpython

因为GDB会试着在当前目录（$cwd）下寻找源代码，所以这个做法也是可以的。

编译时增加-fdebug-prefix-map选项

你可以使用-fdebug-prefix-map = old_path = new_path编译选项来替代构建阶段的源路径。下面是在CPython项目中执行此操作的例子：

$ make distclean    # start clean
$ ./configure CFLAGS="-fdebug-prefix-map=$(pwd)=/usr/src/python" --with-pydebug
$ make -j

这样，我们就有了新的源代码路径：

$ objdump -g ./python
...
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0xb65): GNU C99 6.3.1 20161221 (Red Hat 6.3.1-1) -mtune=generic -march=x86-64 -g -Og -std=c99
    <10>   DW_AT_language    : 12       (ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x10ff): ./Programs/python.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x558): /usr/src/python
    <19>   DW_AT_low_pc      : 0x41d336
    <21>   DW_AT_high_pc     : 0x1b3
    <29>   DW_AT_stmt_list   : 0x0
...

这个办法是最粗暴了，因为你可以将其设置为类似于`/usr/src/project-name’这样的路径，把源代码包安装到这个路径下，然后就可以任性地调试了。

结论

GDB通过以DWARF格式存储的调试信息来查找源代码信息。DWARF是一种非常简单的格式，实际上，它是一棵DIE（调试信息条目）树，它描述了程序的对象文件以及变量和函数。

有很多种方法可以让GDB找到源代码，其中最简单的方法是使用directory和set substitute-path命令，而-fdebug-prefix-map是最最强大的。

秒客网

如何在GDB中关联源代码

调试信息

GDB如何寻找源代码

如何告诉GDB源代码的位置

结论

相关文章