随想录(软件调试)

时间:2022-03-01 05:52:37

【 声明:版权所有,欢迎转载,请勿用于商业用途。  联系信箱:feixiaoxing @163.com】


    对于很多程序员朋友来说,编写代码要比调试代码快乐的多。似乎创造软件比维护软件更能给人带来成就感。然而,在企业里面维护前人留下的代码也是工作中不可缺少的一项内容。所以,如何调试软件,更快更好地寻找软件中的bug,就成了我们必须学习的一门功课。当然,有人查找故障很快,而有的人却要慢一点,这中间的原因很多,比如说对业务的熟悉程度,对调试工具的使用程度。这也从一方面说明了,掌握软件调试的技巧是十分重要的。这里讨论的内容,不是指怎么用visual studio或者是gdb、kgdb、systemtap调试,而是说说调试软件的基本原理是什么。说到底,调试软件也是软件,它需要芯片、操作系统、编译软件、堆栈格式的支持。


(1)芯片的支持

    很多朋友都喜欢在软件运行的过程中设置断点,比如说在代码中插入一个__asm__ ("int $3" ::)就可以达到这样的效果。关键是为什么插入这个代码就会有这样的效果。原来在x86芯片中,上面的int 3会被翻译成0xCC。当cpu遇到这样一行指令的时候,自身就会产生异常,进而会查找相应的异常函数进行处理。在x86中是存在专门的调试指令的,但是在某些cpu中这样的指令却未必存在,比如说powerpc,那这个时候怎么办呢?其实也简单,只需要把对应的指令替换成cpu不认识的指令即可,这样同样可以产生异常的效果。至于当前异常是不是调试异常,那么就需要操作系统来判断了。


(2)操作系统的支持

    芯片本身只是负责产生异常,寻找到异常处理函数,至于这样的函数还要做些什么,那就是操作系统要负责的事情了。比如说,现在我们要调试的程序已经运行到断点了,那么操作系统就要通知gdb或者visual studio当前的程序已经运行到节点了,接下来要做什么。在一般的软件调试中,功能其实都大同小异,比如说查看寄存器、查看内存、设置断点、取消断点、查看线程号、继续运行等等。这些都需要操作系统本身的支持,否则作为用户侧的gdb怎么知道当前的调试程序运行到什么地方了,它的基本信息在哪里等等。毕竟,gdb本身也是一个软件,它关于调试程序的具体信息都是别人告诉它的,它又不是神。


(3)编译软件的支持

    有了芯片和操作系统的支持,其实就可以调试软件了,比如说wingdb就是这么干的。但是,我们还不是很满足,为什么?因为有的时候,我们还需要知道函数的参数值、全局变量是多少,有没有发生改变,C语言代码有没有对应的汇编代码,能否实现汇编级的调试等等。当然,这些信息对于执行文件本身的运行其实是无关紧要的,只是我们为了调试软件的时候使用的。所以,在visual studio编译的软件版本当中有Debug版本,有release版本之分;有普通的软件版本,有优化的软件版本。在linux上,人们为了调试的需要,也会在gcc调试的选项中添加-g选项,获得额外的调试信息。


(4)堆栈的支持

    在调试软件中,有一项非常棒的内容,那就是函数堆栈查看功能。堆栈会根据临时变量的添加、减少进行浮动处理。可以说掌握了堆栈就掌握了cpu、掌握了编程、掌握了软件调试。在x86中,ebp是比较神奇的寄存器。在堆栈中,ebp[0]保存了上一个ebp的地址,ebp[1]保存了返回函数的地址。通过迭代,就可以的得到所有的函数指针了。当然,通过编译器可以生成软件的systemp map文件,也就记录所有函数的空间地址。把返回地址和system map联系在一起,我们就可以知道当前代码的函数堆栈了。除此之外,我们还可以利用堆栈中的返回地址设置断点,这样可以在当前函数运行到结束的时候断住,使用起来也是十分方便。

void print_function_addr(int ebp, int level){
int* start;
int index;
if(0 == ebp || 0 == level)
return;

start = (int*)ebp;
index = 0;
while(index < level){
printf("[%d] 0x%08x\n", index, start[1]);
index ++;
start = (int*)start[0];
}
}

(5)日志和计数器

    依靠系统本身的调试软件当然是不够的,所以为了看清数据的运行流程,我们还需要获得一些额外的调试信息了。所以,对于业务而言,我们需要按照告警、错误、数据格式分别进行日志保存。当然,有时候我们还要对业务性能、频率进行衡量和比较,所以很多时候计数器也是必不可少的。这些信息都是正常代码之外的额外信息,所以处理好他们和普通代码之间的关系也是一门大学问。同时,日志有时还要受到多线程、效率、异常等因素的影响,所以思考和执行的时候一定要顾虑周全。


(6)调试原则

    这些调试原则只是我个人的一些经验总结,谈不上真知灼见,仅供大家参考。1)先排除硬件,后软件。特别高频信号要注意时序和信号完整性;2)软件设计大于调试;3)软件早调试早得益;4)复杂的功能调试可以在仿真软件上进行,比如说全局地址越界等,使用gdb的条件断点调试就十分方便,在嵌入式设备上查找却十分困难;5)尽量自己编写调试函数,不断改进和优化处理,用得也顺手;6)日志模块要健壮,尤其要适合多线程处理;7)定位故障一定要寻找到根本原因,否则极易生成新的故障。