2.8 gdb实用调试技巧

这里讲解gdb的一些实用调试技巧。

2.8.1 将print输出的字符串或字符数组完整显示

当我们使用 print命令打印一个字符串或者字符数组时，如果该字符串太长，则使用print命令默认显示不完整，这时可以通过在gdb中输入set print element 0进行设置，这样再次使用print命令就能完整地显示该变量的所有字符串了：

通过以上代码，在第1次使用print命令输出friendlist变量值时，只能显示部分字符串。使用set print element 0设置后就能完整显示了：

2.8.2 让被gdb调试的程序接收信号

先看看下面这段程序：

在上面这段程序中，我们让程序在接收到Ctrl+C信号（对应的信号值是SIGINT）时简单打印一行信息。我们用gdb调试这个程序时，由于Ctrl+C信号默认会被gdb接收（让调试器中断），所以导致我们无法模拟程序接收这一信号。有以下两种方法解决这个问题。

（1）在gdb中使用signal函数手动向我们的程序发送信号，这里就是signal SIGINT。

（2）改变gdb信号处理的设置，通过handle SIGINT nostop print告诉gdb在接收到SIGINT时不要停止，并把该信号传递给目标调试程序：

2.8.3 函数明明存在，添加断点时却无效

有时，一个函数明明存在，在我们的程序中也存在调试符号，但使用 break functionName添加断点时，gdb却提示如下：

这时即使输入 y，添加的断点可能也不会正确触发。我们需要改变添加断点的策略，使用该函数所在的代码文件和行号添加断点，这样就能添加同样效果的断点了。

2.8.4 调试中的断点

在实际调试中，我们一般会用到3种断点：普通断点、条件断点和数据断点。

普通断点就是我们添加的断点除去条件断点和硬件断点的断点。

数据断点是被监视的内存值或者变量值发生变化时触发的断点，前面介绍watch命令时添加的部分断点就是数据断点。

下面重点介绍条件断点。条件断点就是满足某个条件才会触发的断点。这里举个直观的例子：

在以上代码中，假如我们希望在变量i等于5000时，进入do_something_func函数中追踪这个函数的执行细节，则可以修改代码，增加一个i=5000的if条件，然后重新编译链接调试。这样显然比较麻烦，尤其是对于一些大型项目，每次重新编译链接都需要花一定的时间，而且调试完了还得把程序修改回来。有了条件断点，我们就不需要这么麻烦了，直接添加一个条件断点即可。添加条件断点的命令是break [lineNo] if [condition]，其中lineNo 是程序触发断点后需要停的位置，condition 是断点触发的条件。这里可以将其写成break 11 if i==5000，11就是调用do_something_fun函数所在的行号。当然这里的行号必须是合理的行号，如果行号非法或者行号位置不合理，则也不会触发这个断点：

把i打印出来，gdb确实在i=5000时停了下来。

添加条件断点还有一种方法，就是先添加一个普通断点，然后使用“condition 断点编号 断点触发条件”这样的格式来添加。我们通过这种方法添加上述断点：

同样，如果断点编号不存在，也无法添加成功，gdb就会提示断点不存在：

No breakpoint number 2.

2.8.5 自定义gdb调试命令

在某些场景下，我们需要根据自己的程序自定义一些可以在调试时输出程序特定信息的命令。这在gdb中很容易做到，只要在Linux用户根目录下，root用户就对应/root目录，非 root 用户对应/home/用户名目录，在上述目录下自定义一个.gdbinit 文件即可。注意，在 Linux系统中这是一个隐藏文件，可以使用 ls-a命令查看；如果文件不存在，则新建一个即可，然后在这个文件中写上自定义的gdb命令。

这里以Apache Web Server源码为例（可从Apache官网下载该源码），在其源码根目录下有个.gdbinit文件，在这个文件中存储了Apache Web Server自定义的gdb命令：

当然，在这个文件的底部已配置不让gdb调试器处理SIGPIPE和SIGUSR1这两个信号，而是将这两个信号直接传递给被调试的程序本身，即如果在使用gdb调试Apache Web Server时产生了SIGPIPE或SIGUSR1信号，则gdb本身不处理这两个信号，而是将这两个信号传递给Apache Web Server程序。