用图文带你彻底弄懂 GDB 调试原理
扫描二维码
随时随地手机看文章
一、前言
这篇文章来聊聊大名鼎鼎的GDB,它的豪门背景咱就不提了,和它的兄弟GCC一样是含着金钥匙出生的,在GNU的家族中的地位不可撼动。相信每位嵌入式开发工程师都使用过gdb来调试程序,如果你说没有用过,那只能说明你的开发经历还不够坎坷,还需要继续被 BUG吊打。我们都知道,在使用gcc编译时,可以使用-g选项在可执行文件中嵌入更多的调试信息,那么具体嵌入了哪些调试信息?这些调试信息是如何与二进制的指令之间进行相互交互?在调试的时候,调试信息中是如何获取函数调用栈中的上下文信息?针对上面这些疑惑,道哥用两篇文章把这些底层最深处的问题彻底描述清楚,让你一次看过瘾。第一篇文章,就是当前这一篇,主要内容是介绍GDB的底层调试原理,我们来看一下GDB是通过什么机制来控制被调试程序的执行顺序。第二篇文章,我们选择一个体积小巧、五脏俱全的LUA语言来进行剖析,从源代码分析到函数调用栈,从指令集到调试库的修改,一网打尽。内容比较多,看完本文需要的时间可能长一些,为了您的健康,不建议在处于蹲姿的时候阅读这篇文章。二、GDB调试模型
GDB调试包括2个程序:gdb程序和被调试程序。根据这2个程序是否运行在同一台电脑中,可以把GDB的调试模型分为2种:- 本地调试
- 远程调试
三、GDB调试指令
为了完整性,这里把部分GDB调试指令贴一下,有感性认识即可。另外,这里没有列举所有的指令,列出的指令都是常用的,比较容易理解。在讲解LUA的时候,我们会选择其中的某些指令进行详细的对比,包括底层的实现机制。每一个调试指令都有很多的命令选项,例如断点相关的就包括:设置断点、删除断点、条件断点、临时停用启用等等。这篇文章的重点是理解gdb底层的调试机制,所以应用层的这些指令的使用方法就不再列出了,网络上的资源很多。四、GDB与被调试程序之间的关系
为了方便描述,先写一个最最简单的C程序:#include
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()来创建一个子进程,这个子进程做两件事情:
- 调用系统函数ptrace(PTRACE_TRACEME,[其他参数]);
- 通过execc来加载、执行可执行程序test,那么test程序就在这个子进程中开始执行了。
#include
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
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件事情:
- 对第5行源码所对应的第10行汇编代码存储到断点链表中。
- 在汇编代码的第10行,插入中断指令INT3,也就是说:汇编代码中的第10行被替换为INT3。
- 把汇编代码中的第10行"INT3"替换为断点链表中原来的代码。
然后,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中的调试指令还有很多,包括更复杂的获取堆栈信息、修改变量的值等等,有兴趣的小伙伴可以继续深入跟踪。- EOF -