Linux下的调试工具

Linux下的调试工具

 随着XP的流行，人们愈来愈注重软件的前期设计、后期的实现，以及贯穿于其中的测试工做，通过这个过程出来的天然是高质量的软件。甚至有人声称XP会淘汰调试器！这固然是有必定道理的，然而就目前的现实来看，这仍是一种理想。在平常工做中，调试工具仍是必不可少的。在Linux下，调试工具并不是只有gdb，还有不少其它调试工具，它们都各有所长，侧重方面也有所不一样。本文介绍几种笔者经常使用的调试工具：

•  1. mtrace

在linux下开发应用程序，用C/C++语言的居多。内存泄露和内存越界等内存错误，无疑是其中最头疼的问题之一。glibc为解决内存错误提供了两种方案：

 一种是hook内存管理函数。hook内存管理函数后，你能够经过记下内存分配的历史记录，在程序终止时查看是否有内存泄露，这样就能够找出内存泄露的地方了。你也能够经过在所分配内存的首尾写入特殊的标志，在释放内存时检查该标志是否被破坏了，这样就能够达到检查内存越界问题的目的。

 另一种方法更简单，glibc已经为第一种方案提供了默认的实现，你要作的只是在特定的位置调用mtrace/muntrace两个函数，它们的函数原型以下：

       #include <mcheck.h>

       void mtrace(void);

void muntrace(void);

你可能会问，在哪里调这两种函数最好？这没有固定的答案，要视具体状况而定。对于小程序来讲，在进入main时调用mtrace，在退出main函数时调用muntrace。对于大型软件，这样作可能会记录过多的信息，分析这些记录会比较慢，这时能够在你所怀疑代码的两端调用。

 另外，还须要设置一个环境变量MALLOC_TRACE，它是一个文件名，要保证当前用户有权限建立和写入该文件。glibc的内存管理器会把内存分配的历史信息写入到MALLOC_TRACE指定的文件中。

程序运行完毕后，使用mtrace工具分析这些内存分配历史信息，能够查出内存错误的位置（mtrace在glibc-utils软件包里)。

•  2. strace

在编程时，检查函数的返回值是一种好习惯。对于像glibc等标准C的函数，光检查返回值是不够的，还须要检查errno的值。这样的程序每每显得冗长，不够简洁。同时也多是出于偷懒的缘由，大多数程序里并无作这样的检查。

 这样的程序，一旦出现错误，用调试器一步一步定位错误，而后想法查出错误的缘由，也是能够的，不过比较麻烦，对调试器来讲有些大材小用，不太可取。这时，用strace命令可能会更方便一点。它能够显示各个系统调用/信号的执行过程和结果。好比文件打开出错，一眼就看出来了，连错误的缘由(errno)都知道。

•  3. binutil

binutil是一系列的工具，你可能根本不知道它们的存在，可是没有它们你却步履维艰。Binutil包括下列工具：

• ld - the GNU linker.
• as - the GNU assembler.
• addr2line - Converts addresses into filenames and line numbers.
• ar - A utility for creating, modifying and extracting from archives.
• c++filt - Filter to demangle encoded C++ symbols.
• gprof - Displays profiling information.
• nlmconv - Converts object code into an NLM.
• nm - Lists symbols from object files.
• objcopy - Copys and translates object files.
• objdump - Displays information from object files.
• ranlib - Generates an index to the contents of an archive.
• readelf - Displays information from any ELF format object file.
• size - Lists the section sizes of an object or archive file.
• strings - Lists printable strings from files.
• strip - Discards symbols.
• windres - A compiler for Windows resource files.

其中部分工具对调试极有帮助，如：

你能够用objdump反汇编，查看目标文件或可执行文件内部信息。

你能够用addr2line把机器地址转换到代码对应的位置。

你能够用nm查看目标文件或可执行文件中的各类符号。

你能够用gprof分析各个函数的使用状况，找出性能的瓶颈所在(这须要加编译选项)。

•  4. ld-linux

如今加载ELF可执行文件的工做，已经落到ld-linux.so.2头上了。你可能会问，这与有调试程序有关系吗？有的。好比，在linux中，共享库里全部非static的函数/全局变量都是export的，更糟的是C语言中没有名字空间这个概念，致使函数名极易冲突。在多个共享库中，名字冲突引发的BUG是比较难查的。这时，你能够经过设置LD_ DEBUG环境变量，来观察ld-linux.so加载可执行文件的过程，从中能够获得很多帮助信息。LD_ DEBUG的取值以下：

• libs        display library search paths
• reloc       display relocation processing
• files       display progress for input file
• symbols     display symbol table processing
• bindings    display information about symbol binding
• versions    display version dependencies
• all         all previous options combined
• statistics  display relocation statistics
• unused      determined unused DSOs
• help        display this help message and exit
• 
  
• 5. gdb

对于真正意义的调试器来讲，gdb在linux下是独一无二的。它有多种包装，有字符界面的，也有图形界面的，有单独运行的，也有集成到IDE中的。gdb功能强大，图形界面的gdb容易上手一点，但功能无疑受到了一些限制，相信大部分高手仍是愿意使用字符界面的。Gdb太经常使用了，这里再也不多说。

 

•  6. gcc/boundschecker

相信不少人用过win32下的BoundsChecker(Compuware公司)和Purify(IBM公司)两个工具吧。它们的功能实在太强大了，绝非能经过重载内存管理函数就能够作到，它们在编译时插入了本身的调试代码。

 gcc也有个扩展，经过在编译时插入调试代码，来实现更强大的检查功能。固然这要求从新编译gcc，你能够到http://sourceforge.net/projects/boundschecking/ 下载gcc的补丁。它的可移植性很是好，笔者曾一个ARM 平台项目里使用过，效果不错。

 

•  7. valgrind

最好的东西每每最后才见到。Valgrind是个人最爱，用习惯了，写的程序不在valgrind下跑一遍，就像没有写单元测试程序同样，有点放心不下。它有BoundsChecker/Purify的功能，并且速度更快。有点遗憾的是valgrind目前只支持x86平台，固然，这对大多数状况已经足够了。
你能够到http://valgrind.org/ 下载最新版本。

 

valgrind应该学会使用一下！

 

转载于http://my.oschina.net/mavericsoung/blog/145227