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