用图文带你彻底弄懂GDB调试原理

你的名字 2022-10-30 10:27 233阅读 0赞

> > 本文主要讲了GDB的模型，使用，断点指令和单步指令。是目前相关资料中比较全面的介绍，更可贵的是断点和单步指令的解析是网上很找到的知识点。这也是很多调试工具的本质所在，比如之前讲的kprobe，熟悉我公号的朋友应该知道我之前写了篇《内核调测工具kprobe之实践篇》，由于计划后续会写《内核调测工具kprobe之原理篇》，而其中设计到的断点和单步指令也是其核心，所以以这篇文章为引，我们先初步了解下。

## 一、前言 ##

这篇文章来聊聊大名鼎鼎的GDB，它的豪门背景咱就不提了，和它的兄弟GCC一样是含着金钥匙出生的，在GNU的家族中的地位不可撼动。相信每位嵌入式开发工程师都使用过gdb来调试程序，如果你说没有用过，那只能说明你的开发经历还不够坎坷，还需要继续被 BUG吊打。

![format_png][]

我们都知道，在使用gcc编译时，可以使用-g选项在可执行文件中嵌入更多的调试信息，那么具体嵌入了哪些调试信息？这些调试信息是如何与二进制的指令之间进行相互交互？在调试的时候，调试信息中是如何获取函数调用栈中的上下文信息？

针对上面这些疑惑，道哥用两篇文章把这些底层最深处的问题彻底描述清楚，让你一次看过瘾。

第一篇文章，就是当前这一篇，主要内容是介绍GDB的底层调试原理，我们来看一下GDB是通过什么机制来控制被调试程序的执行顺序。

第二篇文章，我们选择一个体积小巧、五脏俱全的LUA语言来进行剖析，从源代码分析到函数调用栈，从指令集到调试库的修改，一网打尽。

内容比较多，看完本文需要的时间可能长一些，为了您的健康，不建议在处于蹲姿的时候阅读这篇文章。

## 二、GDB调试模型 ##

GDB调试包括2个程序：gdb程序和被调试程序。根据这2个程序是否运行在同一台电脑中，可以把GDB的调试模型分为2种:

1.  本地调试
2.  远程调试

本地调试：调试程序和被调试程序运行在同一台电脑中。

![format_png 1][]

远程调试：调试程序运行在一台电脑中，被调试程序运行在另一台电脑中。

![format_png 2][]

关于可视化调试程序并不是重点，它只是一个用来封装GDB的外壳而已。我们既可以用黑乎乎的终端窗口来手动输入调试命令；也可以选择集成开发环境(IDE)，这个IDE中已经嵌入了器调试，这样就可以使用各种button来代替手动输入调试命令了。

与本地调试相比，远程调试中多了一个GdbServer程序，它和目标程序都是运行在目标机中，可能是一台x86电脑或者是一个ARM板子。图中的红线表示GDB与GdbServer之间通过网络或者串口进行通讯。既然是通讯，那么肯定需要一套通讯协议：RSP协议，全称是：GDB Remote Serial Protocol(GDB远程通信协议)。

关于通讯协议的具体格式和内容，我们不需要关心，只需要知道：它们都是字符串，有固定的开始字符('$')和结束字符('\#')，最后还有两个十六进制的ASCII字符作为校验和，了解这么多就足够了。至于更多的细节，如果实在闲的XX可以瞄几眼，其实这些协议，就像社会中各种奇葩的规定一样，都是一帮砖家在厕所里想出来的。

![format_png 3][]

在第二篇讲解LUA的文章中，我们会实现一个类似的远程调试原型。其中的通信协议也是字符串，直接把 HTTP 协议进行简化之后就拿过来使用了，十分清晰、方便。

## 三、GDB调试指令 ##

为了完整性，这里把部分GDB调试指令贴一下，有感性认识即可。

![format_png 4][]

另外，这里没有列举所有的指令，列出的指令都是常用的，比较容易理解。在讲解LUA的时候，我们会选择其中的某些指令进行详细的对比，包括底层的实现机制。

每一个调试指令都有很多的命令选项，例如断点相关的就包括：设置断点、删除断点、条件断点、临时停用启用等等。这篇文章的重点是理解gdb底层的调试机制，所以应用层的这些指令的使用方法就不再列出了，网络上的资源很多。

## 四、GDB与被调试程序之间的关系 ##

为了方便描述，先写一个最最简单的*C*程序：

#include <stdio.h>
    int main(int argc, char *argv[]){    int a = 1;    int b = 2;    int c = a + b;    printf("c = %d \n", c);    return 0;}

编译命令:

> $ gcc -g test.c -o test

我们对可执行程序 test 进行调试，输入命令：

> $ gdb ./test

输出如下：![format_png 5][]

在最后一行可以看到光标在闪烁，这是gdb程序在等着我们给它下达调试命令呢。

当上面这个黑乎乎的终端窗口在执行gdb ./test的时候，在操作系统里发生了很多复杂的事情：

系统首先会启动gdb进程，这个进程会调用系统函数fork()来创建一个子进程，这个子进程做两件事情：

1.  调用系统函数ptrace(PTRACE\_TRACEME，\[其他参数\])；
2.  通过execc来加载、执行可执行程序test，那么test程序就在这个子进程中开始执行了。

![format_png 6][]

补充一点：文中有时称之程序，有时称之进程。“程序”描述的是一个静态的概念，就是一堆数据躺着硬盘上，而“进程”描述的是动态的过程，是这个程序被读取、加载到内存上之后，在操作系统中有一个任务控制块(一个数据结构)，专门用来管理这个进程的。

铺垫了半天，终于轮到主角登场了，那就是系统调用函数ptrace（其中的参数后面会解释），正是在它的帮助下，gdb才拥有了强大的调试能力。函数原型是：

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

我们先来看一下 man 中对这个函数的简介：

![format_png 7][]

tracer就是调试程序，可以理解为gdb程序；tracee就是被调试程序，对应于图中的目标程序test。一般喜欢用-er和-ee来表示主动和被动的关系，例如：employer就是雇主(老板)，employee就是苦逼的被雇佣者(打工人)。

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

也就是说，如果没有gdb调试，操作系统与目标进程之间是直接交互的；如果使用gdb来调试程序，那么操作系统发送给目标进程的信号就会被gdb截获，gdb根据信号的属性来决定：在继续运行目标程序时是否把当前截获的信号转交给目标程序，如此一来，目标程序就在gdb发来的信号指挥下进行相应的动作。

![format_png 8][]

## 五、GDB如何调试已经执行的服务进程 ##

是否有小伙伴会提出这样一个疑问：上面被调试的程序test是从头开始执行的，是否可以用gdb来调试一个已经处于执行中的服务进程呢？答曰：可以。这就涉及到ptrace系统函数的第一个参数了，这个参数是一个枚举类型的值，其中重要的是2个：PTRACE\_TRACEME和PTRACE\_ATTACH<。

在上面的讲解中，子进程在调用ptrace系统函数时使用的参数是PTRACE\_TRACEME，注意橙色文字：是子进程调用ptrace，相当于子进程对操作系统说：gdb进程是我的爸爸，以后你有任何想发给我的信号，请直接发给gdb进程吧！

如果想对一个已经执行的进程B进行调试，那么就要在gdb这个父进程中调用ptrace(PTRACE\_ATTACH,\[其他参数\])，此时，gdb进程会attach(绑定)到已经执行的进程B，gdb把进程B收养成为自己的子进程，而子进程B的行为等同于它进行了一次 PTRACE\_TRACEME操作。此时gdb进程会发送SIGSTO信号给子进程B，子进程B接收到SIGSTOP信号后，就会暂停执行进入TASK\_STOPED状态，表示自己准备好被调试了。

![format_png 9][]

所以，不论是调试一个新程序，还是调试一个已经处于执行中状态的服务程序，通过ptrace系统调用，最终的结果都是：gdb程序是父进程，被调试程序是子进程，子进程的所有信号都被父进程gdb来接管，并且父进程gdb可查看、修改子进程的内部信息，包括：堆栈、寄存器等。

关于绑定，有几个限制需要了解一下：不予许自我绑定，不允许多次绑定到同一个进程，不允许绑定1号进程。

## 六、偷窥GDB如何实现断点指令 ##

大道理已经讲完了，这里我们通过设置断点(break)这个调试指令，来偷窥一下 gdb 内部的调试机制。还是以上面的代码为例子，这里再重新贴一下代码：

#include <stdio.h>
    int main(int argc, char *argv[]){    int a = 1;    int b = 2;    int c = a + b;    printf("c = %d \n", c);    return 0;}

来看一下编译出来的反汇编代码是什么样的，编译指令：

> gcc -S test.c; cat test.S)

![format_png 10][]

这里只贴了一部分反汇编代码，只要能说明底层的原理就达到我们的目的了。

上面说到，在执行gdb ./test之后，gdb就会fork出一个子进程，这个子进程首先调用ptrace然后执test程序，这样就准备好调试环境了。

我们把源码和汇编代码放在一起，方便理解：

![format_png 11][]

在调试窗口输入设置断点指令“break 5”，此时gdb做2件事情：

1.  对第5行源码所对应的第10行汇编代码存储到断点链表中。
2.  在汇编代码的第10行，插入中断指令INT3，也就是说：汇编代码中的第10行被替换为INT3。

![format_png 12][]

然后，在调试窗口继续输入执行指令“run”(一直执行，直到遇到断点就暂停)，汇编代码中PC指针(一个内部指针，指向即将执行的那行代码)执行第10行时，发现是INT3指令，于是操作系统就发送一个SIGTRAP信号给test进程。

此刻，第10行汇编代码被执行过了，PC指针就指向第11行了。

![format_png 13][]

上面已经说过，操作系统发给test的任何信号，都被gdb接管了，也就是说gdb会首先接收到这SIGTRAP个信号，gdb发现当前汇编代码执行的是第10行，于是到断点链表中查找，发现链表中存储了第10行的代码，说明第10行被设置了断点。于是gdb又做了2个操作：

1.  把汇编代码中的第10行"INT3"替换为断点链表中原来的代码。

2. 把 PC 指针回退一步，也即是设置为指向第10 行。

然后，gdb继续等待用户的调试指令。

![format_png 14][]

此刻，就相当于下一条执行的指令是汇编代码中的第10行，也就是源码中的第5行。从我们调试者角度看，就是被调试程序在第5行断点处暂停了下来，此时我们可以继续输入其他调试指令来debug，比如：查看变量值、查看堆栈信息、修改局部变量的值等等。

## 七、偷窥GDB如何实现单步指令next ##

还是以刚才的源代码和汇编代码为例，假设此时程序停止在源码的第6行，即汇编代码的第11行：

![format_png 15][]

在调试窗口输入单步执行指令next，我们的目的是执行一行代码，也就是把源码中第6行代码执行完，然后停止在第7行。gdb在接收到next执行时，会计算出第7行源码，应该对应到汇编代码的第14行，于是gdb就控制汇编代码中的PC指针一直执行，直到第13行执行结束，也就是PC指向第14行时，就停止下来，然后继续等待用户输入调试指令。

![format_png 16][]

## 八、总结 ##

通过break和next这2个调试指令，我们已经明白了gdb中是如何处理调试指令。当然，gdb中的调试指令还有很多，包括更复杂的获取堆栈信息、修改变量的值等等，有兴趣的小伙伴可以继续深入跟踪。

![虚线阴影分割线][format_png 17]

![format_png 18][]

5T技术资源大放送！包括但不限于：C/C++，Arm, Linux，Android，人工智能，单片机，树莓派，等等。在公众号内回复「peter」，即可免费获取！！

![format_png 19][] **记得点击****分享****、****赞****和****在看****，给我充点儿电吧**

[format_png]: /images/20221024/33562cfadfa1414faed6e2b26ee3e865.png
[format_png 1]: /images/20221024/d50ead6d55ef4fe1bcbe91d82c81aadd.png
[format_png 2]: /images/20221024/dd26a2105e884789a87ab11bed4d5c3f.png
[format_png 3]: /images/20221024/5141af739de546c284530187ccc4d675.png
[format_png 4]: /images/20221024/79960de71a074cc5b03cdd2f835c4203.png
[format_png 5]: /images/20221024/a67880e8e70c49e1b716cee0499b79c2.png
[format_png 6]: /images/20221024/c1d52358b9614a3b87285dac145da97b.png
[format_png 7]: /images/20221024/4f98fb7bd2f44d27b88aafaf30eabd24.png
[format_png 8]: /images/20221024/8ee081b9afeb463c9453e402a76ce357.png
[format_png 9]: /images/20221024/86cdfcd09512481f9eefd6f9f55df38c.png
[format_png 10]: /images/20221024/0757a23439324950919836932ad9e302.png
[format_png 11]: /images/20221024/2f94d02f048c4f2abe61fced1826976b.png
[format_png 12]: /images/20221024/f36c3d6e86304dd79252e8f687954b97.png
[format_png 13]: /images/20221024/4398e1f472e74cbf93209c8748cac53c.png
[format_png 14]: /images/20221024/85f1e35e0d0f45d8bc7e6dc8ae9ae937.png
[format_png 15]: /images/20221024/097e61e37f9f4a3dbb6a88026b4a100b.png
[format_png 16]: /images/20221024/294f4162cb93486591df02867eab1ae1.png
[format_png 17]: /images/20221024/3b3e36dea1584bbf843dd2fb97f9d01f.png
[format_png 18]: /images/20221024/9395396584fb4726a7eb2af146871b11.png
[format_png 19]: /images/20221024/a5d0af9456e64437af83c0fc59a81262.png