运用GDB进行UT/ST的小经验

用惯了VC/Eclipse图形化的程序调试界面后,要适应GDB这种“回归淳朴”的命令行方式,确实需要一些时间。不过当你熟悉了GDB的高级用法后,才能真正体会到程序调试那种随心所欲,尽在掌握的酣畅感。

最近一段时间用GDB作代码测试,积累了一些小小经验,希望对尚未熟悉GDB的朋友有所帮助。(本文以C语言为例说明相应的用法,其它语言可参考GDB帮助文档中对其的支持说明)

业界比较专业的UT(Unit Test,单元测试)工具很多,所以通常不必直接用GDB进行UT,但使用这些专业工具前往往需要花大力气配置环境,编译驱动等,若对于一个小项目,则比直接使用GDB作UT麻烦多了。所以,小项目往往可以借助GDB进行UT/ST合一的测试,效率提升是非常可观的。

ST(System Test,系统测试)一般需要尽可能的逼近实际运行环境,所以应尽量避免或减少对代码有直接介入的工具。这时以GDB作为测试/调试手段就非常实用了。

下面就几个UT/ST中使用频率最多的场景介绍一些GDB的使用经验:

  1. 函数测试 这在UT中使用最多,同时也是部分ST用例的入口。GDB中可以在Ctrl+C暂停程序执行后,使用call命令调用程序中的任何函数,使用方法与被测程序语言的语法一致,如:

call foo(5, “Hello!”)

函数执行的上下文比较特殊,栈空间是GDB临时分配的特殊内存区域,进程空间与被测函数相同,但与任何具体线程无关。如果使用call进行UT,则你会发现GDB的断点设置对call所调用的函数无效,这是GDB的一个默认保护:任何命令涉及的表达式(函数调用同样被视作表达式)都不受断点影响。为了顺利进行UT,我们必须手动修改这一默认设置:

set debug expression 1

这样就可以break在被call所调用的函数中了。

Tip:如果函数中使用了类printf的输出函数,那么可能在call之后看不到任何输出,那是由于标准输出的缓冲造成的,只需简单的c (continue)一次就可以观察到输出了。

  1. 简单的函数桩 UT中对函数进行打桩是一件非常麻烦的事情,对于小项目,往往会浪费大量的精力。其实,通过GDB,我们可以变相的实现简单的函数桩,且较为便捷。

基本思路就是在需要打桩的函数上设置断点,待进入函数后,根据对函数的打桩需求,可以分别采取如下措施:

(1)直接返回:用GDB的return命令强制返回即可,如果有返回值,直接跟在return后面即可,如:

return 5

(2)执行函数的部分逻辑:这需要借助GDB的执行路径篡改功能。

“jump <行号>”直接跳至对应的代码行继续执行,也可以用“jump *<地址>”跳转到机器指令地址。(题外话:在x86开发环境下,即使像VC这种不支持“执行路径篡改”功能的调试器,也可以通过直接修改寄存器PC的值达到跳转的目的)

  1. 临时数据的构造 在测试一些包含复杂数据类型的代码时,常常需要构造一些复杂结构的临时数据,通常简单易行的办法是直接分配一块临时内存,如:(假设SOME_TYPE是某种复杂数据类型,如typedef的struct、union、enum等)

set $temp = ({SOME_TYPE *} malloc(sizeof(SOME_TYPE)))

然后为临时变量$temp填充相应的数据:

set $temp->some_field = 7

最后将其用作普通的数据参与测试:(假设foo()函数接收SOME_TYPE *类型的参数)

call foo($temp)</ol>

GDB强大的调试功能尚远不止如此,充分运用这些高级特性可以大大节省程序调试的时间,并且达到一些常常在你意料之外的效果。欢迎各位朋友就这方面的话题进行探讨!

Written on May 29, 2007