基本概念

什么是 GDB？

GDB（GNU Debugger），是一个由 GNU 开源组织发布的、UNIX/LINUX 操作系统下的、基于命令行的、功能强大的程序调试工具；GDB 支持断点、单步执行、打印变量、观察变量、查看寄存器、查看堆栈等调试手段；GDB 支持调试多种编程语言编写的程序，包括 C、C++、Go、Objective-C、OpenCL、Ada 等。实际场景中，GDB 更常用来调试 C 和 C++ 程序。

GDB 可以用来做些什么？

一般来说，借助 GDB 调试器可以实现以下几个功能：

1. 程序启动时，可以按照我们自定义的要求运行程序，例如设置参数和环境变量。
2. 可使被调试程序在指定代码处暂停运行，并查看当前程序的运行状态（例如当前变量的值，函数的执行结果等），即支持断点调试。
3. 程序执行过程中，可以改变某个变量的值，还可以改变代码的执行顺序，从而尝试修改程序中出现的逻辑错误。

调试模型

根据 GDB 程序与被调试程序是否运行在同一台机器中，可以把 GDB 的调试模型分为以下两种：

• 本地调试
• 远程调试

本地调试

本地调试指的是调试程序和被调试程序运行在同一台机器中，如下图所示：

可视化调试程序只是对 GDB 操作的一层封装，例如 Visual Studio、CLion 等 IDE 中的可视化调试。当然我们也可以直接通过 bash 来手动输入调试命令。

远程调试

调试程序运行在一台机器中，被调试程序运行在另一台机器中，如下图所示：

GdbServer 的主要工作是负责完成 GDB 与目标程序之间的通信，其采用了 RSP（GDB Remote Serial Protocol） 协议。

安装 GDB

这里以 CentOS 8 举例，来演示 GDB 的安装。

首先查看当前机器中是否存在 GDB：

1

gdb -v

如果提示 bash: gdb: command not found，则说明当前机器没有，继续执行下面的步骤，反之则无需安装。

通过 yum 安装 GDB：

1

sudo yum -y install gdb

如果使用的是官方的 yum 下载源，这里就会报错 Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist，这主要是因为在 2021 年底官方就停止对 CentOS 8 提供服务，这时我们就需要将 yum 源切换为国内的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 进入yum的repos目录
cd /etc/yum.repos.d/

# 修改所有的CentOS文件内容
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*

sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*

# 更新yum源为阿里镜像
wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo

yum clean all

yum makecache

这时候重新通过 yum 安装即可。

实战

启动调试

GDB 的使用前提：需要在编译时加上-g 参数，保留调试信息，否则会提示 no debugging symbols found，无法使用 GDB 进行调试。

调试未运行的程序

无参数

使用 GDB 可执行程序名 开启调试，输入 run 命令运行程序：

1
2

gdb test1
(gdb) run

有参数

直接在 run 后面跟上参数：

1
2

gdb test1
(gdb) run "hello world"

也可以通过 set args 命令指定参数列表：

1
2
3
4

gdb test1
(gdb) set args "hello world"
(gdb) show args # 查看参数列表
(gdb) run

调试运行中的程序

如果程序已经处于运行中的状态，那我们该如何对其进行调试呢？

已生成调试信息

对于已生成调试信息的，我们只需要找到它的进程 id，再使用 attach 命令绑定进程即可：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 步骤一：找到进程id
ps -ef|grep 进程名
# 或者
pidof 进程名

# 步骤二：开启GDB调试
gdb

# 步骤三：attach绑定对应的进程id
attach [进程id]
# 或者在启动时直接指定程序名与进程id
gdb [程序名] --pid [进程id]  

未生成调试信息

对于已运行且未生成调试信息的程序，我们可以重新编译出一个带调试信息的版本，再使用 file 命令将这个版本的符号表读取出来，此时我们再次 attach 程序，就能够进行调试了，并且不需要重新启动程序：

1
2
3
4
5
6

# 步骤一：重新编译一个带调试信息的版本

# 步骤二：使用file加载这个版本的符号表
file [程序名]

# 接下来的步骤与已生成调试信息的一样

调试 core 文件

当一个程序因为出错而导致异常中断的时候，操作系统会将程序当前的状态（如程序运行时的内存，寄存器状态，堆栈指针，内存管理信息）保存为一个 core 文件。我们可以通过使用 GDB 来调试这个文件，来迅速定位导致程序出错的问题。

配置 core 文件生成

首先我们需要使用 ulimit -a 命令查看系统有没有限制 core 文件的生成：

1
2
3

ulimit -c
unlimited # 代表没有限制
0         # 如果结果为零则代表无法生成，如果为其他数字则代表限制生成的个数

配置 coredump 生成，有临时配置和永久配置两种。

• 临时配置：只需要简单的命令即可，但是退出 bash 后就会失效。

  • 1 2	$ ulimit -c unlimited #表示不限制core文件大小 $ ulimit -c n #n为数字，表示core文件大小上限，单位为块，一块默认为512字节

• 永久配置：需要修改内核参数，指定 core 文件名、存放路径与永久配置。

  • 1 2 3 4 5 6 7 8 9 10

    mkdir -p /www/coredump/ chmod 777 /www/coredump/ /etc/profile ulimit -c unlimited /etc/security/limits.conf * soft core unlimited echo "/www/coredump/core-%e-%p-%h-%t" > /proc/sys/kernel/core_pattern

调试 core 文件

这里以一个简单的访问空指针的示例来演示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#include <stdio.h>

void fault_test(void) {
    *((int *)NULL) = 100;	//解引用空指针并尝试修改它的值
}

int main() {
    fault_test();
    return 0;
}

当我们编译后执行程序时，此时就会因为访问空指针而导致段错误：

1
2
3

gcc -g -o test_coredump test_coredump.c
./test_coredump
Segmentation fault (core dumped)

此时查看 core 文件的位置：

1
2

cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e

这时我们发现这个路径下并没有 core 文件，上述信息表明了 core 文件已经被系统转储，此时有两种方法获取到 core 文件：

• 修改生成路径：

  • 1 2	# 直接在程序所在目录生成core文件 echo "core-%e-%p-%t" > /proc/sys/kernel/core_pattern

• 取出 core 文件：

  1. 执行 coredumpctl 命令，查看所有 coredump 的程序，找到我们需要调试的那个。
  2. 执行 coredumpctl -o 自定义core文件名 dump Pid 取回 core 文件。

当生成完毕 core 文件后，执行以下命令开始调试：

1

gdb 程序名 core文件名

此时我们就能够看到 coredump 的原因：

1
2
3
4
5

[New LWP 1065384]
Core was generated by `./test_coredump'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  fault_test () at test_coredump.c:4
4	    *((int *)NULL) = 100;

接着执行 where 命令就能够查看调用堆栈：

1
2
3

(gdb) where
#0  fault_test () at test_coredump.c:4
#1  0x0000000000400551 in main () at test_coredump.c:8

常用命令

在 GDB 中，最常用的命令有以下这些：

下面就来详细的介绍这些命令。

断点

断点是最常用的调试功能之一，它可以让程序中断在需要的地方，从而方便我们对程序分析。GDB 中断点主要分为以下三类：

1. breakpoint。
2. watchpoint。
3. catchpoint。

breakpoint

可以根据行号、函数、条件生成断点，下面是相关命令以及对应的作用说明：

watchpoint

watchpoint 是一种特殊类型的断点，其类似于一个表达式的监视器，即当某个表达式改变了值时，它就会让 GDB 发出暂停执行的命令。

使用数据断点时，需要注意：

• 当监控变量为局部变量时，一旦局部变量失效，数据断点也会失效
• 如果监控的是指针变量p，则watch *p监控的是p所指内存数据的变化情况，而watch p监控的是p指针本身有没有改变指向

最常见的数据断点应用场景：定位堆上的结构体内部成员何时被修改。由于指针一般为局部变量，为了解决断点失效，一般有两种方法。

catchpoint

catchpoint 是捕获断点，其主要监测信号的产生。

调用栈

输出

变量信息

字符串

数组

指针

内存地址

使用 x 命令来打印内存的值，格式为 x/nfu addr，以 f 格式打印从 addr 开始的 n 个长度单元为 u 的内存值。

• n：输出单元的个数
• f：输出格式，如 x 表示以 16 进制输出，o 表示以 8 进制输出，默认为 x
• u：一个单元的长度，b 表示 1 个 byte，h 表示 2 个 byte（half word），w 表示 4 个 byte，g 表示 8 个 byte（giant word）

局部变量

结构体

函数跳转

多线程、多进程

多进程

GDB 在调试多进程程序（程序含 fork 调用）时，默认只追踪父进程。可以通过命令设置，实现只追踪父进程或子进程，或者同时调试父进程和子进程。

在调试多进程程序时候，默认情况下，除了当前调试的进程，其他进程都处于挂起状态，所以，如果需要在调试当前进程的时候，其他进程也能正常执行，那么通过设置 set schedule-multiple on 即可。

在默认情况下，GDB 只支持调试主进程（即 main），只有在 GDB 7.0 后才支持单独调试(调试父进程或者子进程)和同时调试多个进程。

多线程

默认调试多线程时，一旦程序中断，所有线程都将暂停。如果此时再继续执行当前线程，其他线程也会同时执行。

如果只关心当前线程，建议临时设置 scheduler-locking 为 on，避免其他线程同时运行，导致命中其他断点分散注意力。

其他

图形化

tui为terminal user interface的缩写，在启动时候指定-tui参数，或者调试时使用ctrl+x+a组合键，可进入或退出图形化界面。

汇编

其他工具

pstack

pstack 是一个 shell 脚本，用于打印正在运行的进程的栈跟踪信息。pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。

使用方式如下：

1

pstack [pid]

ldd

当我们编译链接时找不到静态库而导致链接失败，又或者是编译成功，在运行时加载动态库失败时，我们可以使用 ldd 命令来分析该程序依赖了哪些库以及这些库所在的路径，从而解程序因缺少某个库文件而不能运行的一些问题。使用方式如下：

1

ldd 程序名

例如：

1
2
3
4
5
6
7

ldd test
	linux-vdso.so.1 (0x00007ffeefb2f000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa30f54a000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fa30f1c8000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa30efb0000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fa30ebeb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa30f8df000)

其中每一行的第一个参数程序依赖的库名，第二个则是系统所提供的对应的库（如果系统找不到，则会显示 not found），第三个是库加载的起始地址。

strings、c++filt

C++ 为了支持函数重载功能，需要编译器在使用 name mangling 机制将符号表中的函数进行重命名，而我们使用 strings 就可以查看到重命名后的函数名：

1

strings 程序名

如果使用 c++filt 工具，就可以根据符号表中的函数名，还原为原始的函数定义：

1

c++filt 重命名后的函数名

原理

调试原理

当我们开始使用 GDB 开始调试时，系统首先会启动一个 GDB 进程，紧接着这个进程会 fork 出一个子进程来控制被调试程序，它会执行以下操作：

1. 调用 ptrace(PTRACE_TRACEME) 来让 GDB 进程接管本进程的执行。
2. 通过 execv 来将被调试程序替换到子进程中。

详细流程如下图所示：

接下来就介绍里面最关键的 ptrace。

ptrace

ptrace 是 Linux 内核提供的一个用于进程跟踪的系统调用，通过它，一个进程（GDB）可以读写另外一个进程（被调试进程）的指令空间、数据空间、堆栈和寄存器的值，并且 GDB 进程接管了被调试进程的所有信号，这样一来，被调试进程的执行就被 GDB 控制，从而达到调试的目的。

ptrace 的定义如下：

1
2

#include <sys/ptrace.h>
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data)

• enum __ptrace_request request：指示了 ptrace 要执行的命令。
• pid_t pid：指示 ptrace 要跟踪的进程
• void *addr：指示要监控的内存地址
• void *data：存放读取出的或者要写入的数据。

调试运行中程序

如果想要调试一个已经执行的进程，就需要在 GDB 进程中调用 ptrace(PTRACE_ATTACH,...)，此时 GDB 进程会 attach 已经执行的被调试进程，将其收养为自己的子进程，接着会向被调试进程发送一个 SIGSTO 信号，当被调试进程接收到这个信号时，就会暂时执行并进入 TASK_STOPED 状态，表示其已经准备好接受调试。

attach 的一些限制：不予许 attach 自己；不允许多次 attach 到同一个进程；不允许 attach 1 号进程；

断点 break

当我们使用 break 命令设置断点的时候，GDB 首先会将原来的汇编代码存储到一个断点链表中，接着会在对应的汇编代码的位置插入一个 INT3 中断指令。

当被调试的程序运行到这个位置时，就会执行 INT3 指令，此时会发生软中断，接着内核会向被调试进程发送一个 SIGTRAP 信号，由于当前 GDB 通过 ptrace 接管了被调试进程，所以这个信号自然又转发到了 GDB 进程中。GDB 此时会对比当前停止的位置和断点链表中存储的断点位置，将该位置的代码恢复成断点链表中存储的原来的代码，接着将程序计数器（pc 指针）回退一步，指向用户 break 的位置。

此时就达到了断点的目的，接着 GDB 会一直等待用户输入调试指令。

单步 next

当我们使用 next 执行单步命令时，此时 GDB 会控制其执行一行代码，它首先会计算出这一行代码所对应的汇编代码的位置，接着控制程序计数器一直往下执行，直到执行到这个位置时就会停下来，继续等待用户输入调试指令。

这个功能其实借助 ptrace 就可以直接实现，只需要在第一个参数中传递 PTRACE_SINGLESTEP 即可。

参考

1. GDB调试-从入门实践到原理
2. GDB调试入门，看这篇就够了
3. 图文并茂 | 彻底弄懂GDB调试原理
4. GDB教程
5. GNU调试器