随 着XP的流行，人们越来越注重软件的前期设计、后期的实现，以及贯穿于其中的测试工作，经过这个过程出来的自然是高质量的软件。甚至有人声称XP会淘汰调 试器！这当然是有一定道理的，然而就目前的现实来看，这还是一种理想。在日常工作中，调试工具还是必不可少的。在Linux下，调试工具并非只有gdb， 还有很多其它调试工具，它们都各有所长，侧重方面也有所不同。本文介绍几种笔者常用的调试工具：
1. mtrace
在linux下开发应用程序，用C/C++语言的居多。内存泄露和内存越界等内存错误，无疑是其中最头疼的问题之一。glibc为解决内存错误提供了两种方案：
一种是hook内存管理函数。hook内存管理函数后，你可以通过记下内存分配的历史记录，在程序终止时查看是否有内存泄露，这样就可以找出内存泄 露的地方了。你也可以通过在所分配内存的首尾写入特殊的标志，在释放内存时检查该标志是否被破坏了，这样就可以达到检查内存越界问题的目的。
另外一种方法更简单，glibc已经为第一种方案提供了默认的实现，你要做的只是在特定的位置调用mtrace/muntrace两个函数，它们的函数原型如下：
#include
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/ 下载最新版本。