查看原文
其他

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

道哥 IOT物联网小镇 2021-12-21

一、前言

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

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

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

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

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

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

二、GDB调试模型

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

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

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

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

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

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

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

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

三、GDB调试指令

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

另外,这里没有列举所有的指令,列出的指令都是常用的,比较容易理解。在讲解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

输出如下:

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

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

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

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

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

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

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

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

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

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

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

五、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状态,表示自己准备好被调试了。

所以,不论是调试一个新程序,还是调试一个已经处于执行中状态的服务程序,通过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)

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

八、总结

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

后面我在写LUA语言中的调试库时,会更深入、详细的讨论这个问题,毕竟LUA语言更小巧、简单。我也会把LUA代码中如何设置PC指针的代码部分给小伙伴演示一下,这样我们对于一门编程语言的内部实现就会有更好的理解和掌握,也可能会录制一个视频,这样就能更好的讲解LUA语言中的内部细节。


如果这篇文章能给你带来小小的帮助,欢迎评论、转发、分享给你的朋友。

我会持续总结项目开发过程中的实战经验,相信不会让你失望的!


: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存