Linux调试工具
1. 使用printf调试
#ifdef DEBUG
Printf(“valriable x has value = %d\n”, x)
#endif
然后在编译选项中加入-DDEBUG
更复杂的调试应用如:
#define BASIC_DEBUG 1
#define EXTRA_DEBUG 2
#define SUPER_DEBUG 4
#if (DEBUG &EXTRA_DEBUG)
printf …
#endif
在这种情况下如果设置编译器标志为-DDEBUG=5,将启用BASIC_DEBUG 和SUPER_DEBUG。 标志-DDEBUG=0将禁用所有的调试信息,也可以在程序中添加如下语句:
#ifndef DEBUG
#define DEBUG 0
#endif
2.使用gdb调试
Gcc编译的时候要加上-g选项,让编译器在程序中添加额外的调试信息。如果正式发布,这些调试信息可以使用strip命令删除。
Gdb:
Backtrace栈跟踪
3. 程序静态分析工具splint
splint功能:
常识性测试并产生一些警告信息。它可以检测未经赋值的变量使用,函数的参数未使用等异常情况。
4. 程序执行性能分析工具prof/gprof
显示执行所花费的时间具体都用在什么操作上。
5. 内存调试
ElectricFence函数库和valgrind可以用来检查动态内存分配的一些问题,包括内存泄漏。
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/ 下载最新版本。
Linux 平台上的C语言调试工具!
Debugging Tools for C on
Linux Platform
http://www.linuxgazette.com/node/view/8755
Submitted by Nikhil Bhargava on Tue, 02/17/2004 - 14:37. Articles | General Interest
This article talks about debugging tools for applications in C on Linux platforms. Most of the tools are freely available on all major platforms with very wide user support. The tools help in static analysis of code as well as assist in dynamic evaluation of code.
Please note that tools listed here are suggestions of the author. This list is not a standard one. Changes have to be done in it depending upon the nature, scope and details of the application to be developed.
Debugging Tools
1. Dmalloc http://dmalloc.com/
The debug memory allocation or Dmalloc library is a freeware debugging tool which has been specially designed as a drop in replacement for the system's malloc, realloc, calloc, free and other memory management routines while providing powerful debugging facilities configurable at runtime. It makes changes during compile time and donot add runtime changes in binary. These facilities include such things as memory-leak tracking, fence-post write detection, file/line number reporting, and general logging of statistics. The library is reasonably portable having been run successfully on at least the following operating systems: AIX, BSD/OS, DG/UX, Free/Net/OpenBSD, GNU/Hurd, HPUX, Irix, Linux, MS-DOG, NeXT, OSF, SCO, Solaris, SunOS, Ultrix, Unixware, Windoze, and even Unicos on a Cray T3E. It has full support for programs the debugging of POSIX threads.
The package includes the library, configuration scripts, debug utility application, test program, and documentation.
2. Valgrind http://valgrind.kde.org/
Valgrind is a GPL distributed system for debugging and profiling x86-Linux programs. I can also be helpful for programs for platforms other than x86 since behavior of x86 binary is similar to other binaries. The accompanying tools with Valgrind automatically detect many memory management and threading bugs, avoiding hours of frustrating bug-hunting, making programs more stable. It supports a through detailed profiling to help speed up the programs.
The Valgrind distribution includes four tools: two memory error detectors, a thread
error detector, and a cache profiler.
3. Electricfence http://rpmfind.net/linux/RPM/conecti...-2cl.i386.html
Electric Fence is a freeware library that can be used for C programming and debugging. It can be linked at compile time and it will warn about possible problems such as freeing memory that doesn't exist, etc. It is basically a memory profiling tool. However currently it is available only on HP-Unix platform (I am not very sure though).
4. GDB http://sources.redhat.com/gdb
This is the Gnome Debugger which comes as a freeware support package with freeware Linux distribution like Red Hat, Slacware, and Debian etc. It has full support of many languages like C, C++, and Perl etc. It helps to debug the binaries of these languages in modes like single step, multiple step or complete run. It also has provisions of setting break points and trace value.
It is helpful for stub testing, functional flow checking and bound checking.
Further this is readily available with all flavours of Linux andUnix platforms and is amply supported in user community.
5. Insight http://sources.redhat.com/insight
Insight is a graphical user interface to GDB, the GNU Debugger written in Tcl/Tk by at Red Hat, Inc. and Cygnus Solutions Insight provides all features provided by GDB along with Graphical debugging interface replacing traditional command based interface.
6. Memprof http://www.gnome.org/projects/memprof
MemProf is a free ware memory Profiling and memory leak detection tool which comes as an addendum to common Linux distributions. It can generate a profile how much memory was allocated by each function in the program. It can scan memory and find blocks that have been allocated but are no longer referenced anywhere (dead code).
MemProf works by pre-loading a library to override the C library's memory allocation functions and does not require recompiling the program. One advantage MemProf has over some other similar tools that are available is that it has a nice GUI front-end and is relatively easy to use.
I am Nikhil Bhargava from Delhi, India. I am a Computer Engineer currently working in C-DOT, India for past one year. Comments and Suggestions are always welcome.
10.3 图形化调试工具
尽管你可以在大多数(即便不是全部)Linux调试 任务中使用GDB,但与长时间坐在GDB命令行前面相比,许多人还是更愿意使用诸如DDD或Eclipse这样的图形化工具。从各方面来看,大多数非常花 哨的图形化调试工具不过是建立在GDB基础上的一个抽象,所以选择哪一种图形化工具完全属于个人爱好。
本节将介绍两个这样的工具,当然还存在其他许多这样的工具(包括GDB的前端GNU insight),它们也被各种开发团队所使用。