动态库和Linux调试技术

Linux支持共享库已经有悠久的历史了，不再是什么新概念了。大家都知道如何编译、连接以及动态加载(dlopen/dlsym/dlclose) 共享库。但是，可能很多人，甚至包括一些高手，对共享库相关的一些环境变量认识模糊。当然，不知道这些环境变量，也可以用共享库，但是，若知道它们，可能就会用得更好。下面介绍一些常用的环境变量，希望对家有所帮助：

ld的环境变量

LD_LIBRARY_PATH 这个环境变量是大家最为熟悉的，它告诉loader：在哪些目录中可以找到共享库。可以设置多个搜索目录，这些目录之间用冒号分隔开。在linux下，还提供了另外一种方式来完成同样的功能，你可以把这些目录加到/etc/ld.so.conf中，或则在/etc/ld.so.conf.d里创建一个文件，把目录加到这个文件里。当然，这是系统范围内全局有效的，而环境变量只对当前shell有效。按照惯例，除非你用上述方式指明，loader是不会在当前目录下去找共享库的，正如shell不会在当前目前找可执行文件一样。

LD_PRELOAD 这个环境变量对于程序员来说，也是特别有用的。它告诉loader：在解析函数地址时，优先使用LD_PRELOAD里指定的共享库中的函数。这为调试提供了方便，比如，对于C/C++程序来说，内存错误最难解决了。常见的做法就是重载malloc系列函数，但那样做要求重新编译程序，比较麻烦。使用LD_PRELOAD机制，就不用重新编译了，把包装函数库编译成共享库，并在LD_PRELOAD加入该共享库的名称，这些包装函数就会自动被调用了。在linux下，还提供了另外一种方式来完成同样的功能，你可以把要优先加载的共享库的文件名写在/etc/ld.so.preload里。当然，这是系统范围内全局有效的，而环境变量只对当前shell有效。

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
BIND_NOW 这个环境变量与dlopen中的flag的意义是一致，只是dlopen中的flag适用于显示加载的情况，而BIND_NOW/BIND_NOT适用于隐式加载。

LD_PROFILE/LD_PROFILE_OUTPUT：为指定的共享库产生profile数据，LD_PROFILE指定共享库的名称，LD_PROFILE_OUTPUT指定输出profile文件的位置，是一个目录，且必须存在，默认的目录为/var/tmp/或/var/profile。通过profile数据，你可以得到一些该共享库中函数的使用统计信息。

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.         binutilbinutil是一系列的工具，你可能根本不知道它们的存在，但是没有它们你却寸步难行。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 pathsreloc       display relocation processingfiles       display progress for input filesymbols     display symbol table processingbindings    display information about symbol bindingversions    display version dependenciesall         all previous options combinedstatistics  display relocation statisticsunused      determined unused DSOshelp        display this help message and exit5.         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/ 下载最新版本。