操作系统中的应用介绍下的

一个盛典 调试 一个功能强大的调试器不仅为程序员提供了跟踪程序执行的手段，而且还可以帮助程序员找到解决问题的方法。对于Linux程序员来讲，GDB（GNU Debugger）通过与GCC的配合使用，为基于Linux的软件开发提供了一个完善的调试环境。 默认情况下，GCC在编译时不会将调试符号插入到生成的二进制代码中，因为这样会增加可执行文件的大小。如果需要在编译时生成调试符号信息，可以使用GCC 的-g或者-ggdb选项。GCC在产生调试符号时，同样采用了分级的思路，开发人员可以通过在-g选项后附加数字1、2或3来指定在代码中加入调试信息的多少。默认的级别是2（-g2），此时产生的调试信息包括扩展的符号表、行号、局部或外部变量信息。级别3（-g3）包含级别2中的所有调试信息，以及源代码中定义的宏。级别1（-g1）不包含局部变量和与行号有关的调试信息，因此只能够用于回溯跟踪和堆栈转储之用。回溯跟踪指的是监视程序在运行过程中的函数调用历史，堆栈转储则是一种以原始的十六进制格式保存程序执行环境的方法，两者都是经常用到的调试手段。 GCC产生的调试符号具有普遍的适应性，可以被许多调试器加以利用，但如果使用的是GDB，那么还可以通过-ggdb选项在生成的二进制代码中包含GDB专用的调试信息。这种做法的优点是可以方便GDB的调试工作，但缺点是可能导致其它调试器（如DBX）无法进行正常的调试。选项-ggdb能够接受的调试级别和-g是完全一样的，它们对输出的调试符号有着相同的影响。 需要注意的是，使用任何一个调试选项都会使最终生成的二进制文件的大小急剧增加，同时增加程序在执行时的开销，因此调试选项通常仅在软件的开发和调试阶段使用。调试选项对生成代码大小的影响从下面的对比过程中可以看出来： # gcc optimize.c -o optimize# ls optimize -l-rwxrwxr-x 1 xiaowp xiaowp 11649 Nov 20 08:53 optimize (未加调试选项)# gcc -g optimize.c -o optimize# ls optimize -l-rwxrwxr-x 1 xiaowp xiaowp 15889 Nov 20 08:54 optimize (加入调试选项)

虽然调试选项会增加文件的大小，但事实上Linux中的许多软件在测试版本甚至最终发行版本中仍然使用了调试选项来进行编译，这样做的目的是鼓励用户在发现问题时自己动手解决，是Linux的一个显著特色。 下面还是通过一个具体的实例说明如何利用调试符号来分析错误，所用程序见清单4所示。 清单4：crash.c #include int main(void){int input =0;printf(\"Input an integer:\");scanf(\"%d\", input);printf(\"The integer you input is %d\\\\n\", input);return 0;}

编译并运行上述代码，会产生一个严重的段错误（Segmentation fault）如下： # gcc -g crash.c -o crash# ./crashInput an integer:10Segmentation fault

为了更快速地发现错误所在，可以使用GDB进行跟踪调试，方法如下： # gdb crashGNU gdb Red Hat Linux (5.3post-0..18rh)……(gdb)

当GDB提示符出现的时候，表明GDB已经做好准备进行调试了，现在可以通过run命令让程序开始在GDB的监控下运行： (gdb) runStarting program: /home/xiaowp/thesis/gcc/code/crashInput an integer:10Program received signal SIGSEGV, Segmentation fault.0xb in _IO_vfscanf_internal () from /lib/.6

仔细分析一下GDB给出的输出结果不难看出，程序是由于段错误而导致异常中止的，说明内存操作出了问题，具体发生问题的地方是在调用_IO_vfscanf_internal ( )的时候。为了得到更加有价值的信息，可以使用GDB提供的回溯跟踪命令backtrace，执行结果如下： (gdb) backtrace#0 0xb in _IO_vfscanf_internal () from /lib/.6#1 0xbffff0c0 in ?? ()#2 0x4008e0ba in scanf () from /lib/.6#3 0x in main () at crash.c:11#4 0x in __libc_start_main () from /lib/.6

跳过输出结果中的前面三行，从输出结果的第四行中不难看出，GDB已经将错误定位到crash.c中的第11行了。现在仔细检查一下： (gdb) frame 3#3 0x in main () at crash.c:1111 scanf(\"%d\", input);