3. 附加调试信息

使用GCC开发程序，与之配套的调试工具便是gdb，简称GUN Debugger，我们常用它来调试GCC编译生成的可执行文件。默认编译生成的可执行文件是无法使用gdb来跟踪或调试的，因为可执行程序中没哟可供gdb调试使用的特殊信息，为了将必要的调试信息整合到可执行文件中，就需要用到-g选项。

下面制造一个“问题”程序，演示一下-g选项的使用，同时体验一下gdb的调试功能。

 

/* year.c */

#include <stdio.h>

 

int main(void)

{

       int num=365;

       printf(“%s days a year\n”,num);

       return 0;

}

 

在编译程序时，警告提示year.c 第7行的格式不匹配，我们忽略它，是为了制造一个问题程序。执行该问题程序，出现段错误，为了记录错误出现的具体位置，我们需要对core文件进行配置。

那什么是core文件呢？当shell中运行的程序因为错误而崩溃时，系统会自动生成一个文件，用于记录崩溃时的系统信息，包括内存和寄存器信息，供程序开发者日后排查问题使用，这个文件就是core文件。一般来说，core文件存放在当前目录，不论崩溃的程序编译时是否加了-g选项，都可以使用“gdb 程序名 core文件名”命令来查看程序崩溃时的相关信息，只是编译时加-g选项的程序崩溃后可以使用gdb通过core文件跟踪到崩溃的具体文件、函数及行数，而未加-g选项的程序崩溃后只能通过core文件跟踪到崩溃后的具体函数。

进入Shell 以后，core文件的大小默认设置为0，这样程序在崩溃以后系统就不会帮我们记录core文件了。为了能够调试，使用命令“ulimit –c unlimited”将core文件大小设置为unlimited(无限大)。执行了“ulimit –c unlimited”命令以后，程序再次崩溃时提示“核心已转储”，即生成了core文件。执行“gdb 程序名 core文件名”来查看崩溃时的相关信息，这时的gdb告诉我们程序最终崩溃在vfprint函数，在gdb内再执行bt命令，用于查看堆栈信息，这下就一母了然了。分析得知程序由year.c的第7行进入printf函数，最终崩溃在vfprint函数，这时我们便可以回到源码year.c的第7行分析printf函数是否存在问题，这样就能很容易的发现printf函数中参数格式不匹配的问题。