为了更快速地发现错误所在，可以使用GDB进行跟踪调试，方法如下：

# gdb crash
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
......
(gdb)



当GDB提示符出现的时候，表明GDB已经做好准备进行调试了，现在可以通过run命令让程序开始在GDB的监控下运行：

(gdb) run
Starting program: /home/xiaowp/thesis/gcc/code/crash
Input an integer:10

Program received signal SIGSEGV, Segmentation fault.
0x4008576b in _IO_vfscanf_internal () from /lib/libc.so.6



仔 细分析一下GDB给出的输出结果不难看出，程序是由于段错误而导致异常中止的，说明内存操作出了问题，具体发生问题的地方是在调用 _IO_vfscanf_internal ( )的时候。为了得到更加有价值的信息，可以使用GDB提供的回溯跟踪命令backtrace，执行结果如下：

(gdb) backtrace
#0 0x4008576b in _IO_vfscanf_internal () from /lib/libc.so.6
#1 0xbffff0c0 in ?? ()
#2 0x4008e0ba in scanf () from /lib/libc.so.6
#3 0x08048393 in main () at crash.c:11
#4 0x40042917 in __libc_start_main () from /lib/libc.so.6



跳过输出结果中的前面三行，从输出结果的第四行中不难看出，GDB已经将错误定位到crash.c中的第11行了。现在仔细检查一下：

(gdb) frame 3
#3 0x08048393 in main () at crash.c:11
11 scanf("%d", input);



使用GDB提供的frame命令可以定位到发生错误的代码段，该命令后面跟着的数值可以在backtrace命令输出结果中的行首找到。现在已经发现错误所在了，应该将

scanf("%d", input);
改为
scanf("%d", &input);



完成后就可以退出GDB了，命令如下：

(gdb) quit



GDB的功能远远不止如此，它还可以单步跟踪程序、检查内存变量和设置断点等。

调 试时可能会需要用到编译器产生的中间结果，这时可以使用-save-temps选项，让GCC将预处理代码、汇编代码和目标代码都作为文件保存起来。如果 想检查生成的代码是否能够通过手工调整的办法来提高执行性能，在编译过程中生成的中间文件将会很有帮助，具体情况如下：

# gcc -save-temps foo.c -o foo
# ls foo*
foo foo.c foo.i foo.s



GCC 支持的其它调试选项还包括-p和-pg，它们会将剖析（Profiling）信息加入到最终生成的二进制代码中。剖析信息对于找出程序的性能瓶颈很有帮 助，是协助Linux程序员开发出高性能程序的有力工具。在编译时加入-p选项会在生成的代码中加入通用剖析工具（Prof）能够识别的统计信息，而- pg选项则生成只有GNU剖析工具（Gprof）才能识别的统计信息。

最后提醒一点，虽然GCC允许在优化的同时加入调试符号信息， 但优化后的代码对于调试本身而言将是一个很大的挑战。代码在经过优化之后，在源程序中声明和使用的变量很可能不再使用，控制流也可能会突然跳转到意外的地 方，循环语句有可能因为循环展开而变得到处都有，所有这些对调试来讲都将是一场噩梦。建议在调试的时候最好不使用任何优化选项，只有当程序在最终发行的时 候才考虑对其进行优化。