The Linux GCC HOWTO中译版V0.1 : Debugging and Profiling
Previous: 移植(Porting)与编译(Compiling)程式
Next: 连结(Linking)

5. Debugging and Profiling

5.1. Preventative maintenance (lint)

lint对Linux而言并没有很广泛的用途,主要是因为大部份的人都能满足於gcc所提供的警告讯息(warnings).可能最有用的就是-Wall参数了---这个参数的用途是要求gcc将所有的警告讯息显现出来.but probably has more mnemonic value if thought of as the thing you bang your head against.

网路上有一个实用的public domain lint,位於 ftp://larch.lcs.mit.edu/pub/Larch/lclint.我并不知道这个站到底有多好就是了.

5.2. 除错(Debugging)

5.2.1. 我要怎样做才能将除错资讯放到一支程式里头?

你需要添加-g的参数来编译与连结程式,而且不可以用-fomit-frame-pointer参数.事实上,你不需要重新编译所有的程式,只需重新编译目前你正在除错的部份即可.

就a.out的格式(configurations)而言,共享程式库(shared libraries)是以-fomit-frame-pointer编译而成,这个时候,gdb就变得英雄无用武之地了.连结时给定-g的选项,应该就隐含著静态连结(static linking)了;这就是为什麽要加-g的原因了.

如果连结器(linker)连结失败,告诉你找不到libg.a,那就是在/usr/lib/的目录底下,少了libg.a.libg.a是特殊的C语言侦错程式库(special debugging-enabled C library).一般在libc的套件内就会提供libg.a;不然的话(新版是这样的),你可能需要拿libc的原始码自己建立了.不过,实际上你应该不需要才对.不管是什麽目的,大部份的情况下,只需将libg.a连结到/usr/lib/libc.a,你就能得到足够的资讯了.

5.2.1.1. 那,能不能把除错资讯给拿掉?

很多的GNU软体在编译连结时,都会设定-g的选项,而这样做会造成执行档过大的问题(通常是静态的).实际上,这并不是一个很热门的想法.

如果程式本身有autoconf,产生了configure命令稿,通常你就可以用./configure CFLAGS=或是./configure CFLAGS=-O2来关掉除错资讯.不然的话,你得检查检查Makefile了.当然啦,假如你用的是ELF,程式便会以动态的方式连结(dynamically linked),不论是否有-g的设定;因此你可以平常心把-g拿掉(strip).

5.2.2. 实用的软体(Available software)

据了解,一般人都使用gdb.你可以从GNU archive sites拿到原始程式;或者是到tsx-11拿可执行档.xxgdb是一个X介面的除错程式(debugger),植基於gdb(也就是说你得先安装好gdb,才能再装xxgdb).xxgdb的原始码可以在ftp://ftp.x.org/contrib/xxgdb-1.08.tar.gz找到.

另外,UPS除错程式已由Rick Sladkey移植成功.UPS可以在X底下活得很好,不像xxgdb那样---仅仅是gdb的X前端介面(X front end).这支除错程式有一大堆优良的特点,and if you spend any time debugging stuff, you probably should check it out.先前编译(precompiled)好的Linux版与修正版(patches)的原始码可以在ftp://sunsite.unc.edu/pub/Linux/devel/debuggers/找到.而最初的原始程式则放在 ftp://ftp.x.org/contrib/ups-2.45.2.tar.Z.

你可能会发现另一个用来除错的工具strace,也是相当的有用.它可以显示出由程序(process)所产生的系统呼叫,而且还拥有其它众多繁复的功能(multiplicity),像是如果你手边没有原始码的话,strace可以帮你找出(figure out)有那些路径(path-names)已编译进执行档(binaries)内; exacerbating race conditions in programs that you suspect contain them;还有,strace可拿来学习程式是怎麽在电脑中执行的.最新的版本(目前是3.0.8)可在找到ftp://ftp.std.com/pub/jrs/.

5.2.3. 背景程式(Background (daemon) programs)

早期典型的常驻程式(daemon programs)是执行fork(),然後终止(terminate)父程序(parent).这样的做法使得除错的时间减短了.

了解(get around)这点的最简单的方法就是替fork()设一个breakpoint.当程式停止时,强迫fork()传回0.

(gdb) list 
1       #include <stdio.h>
2
3       main()
4       {
5         if(fork()==0) printf("child\n");
6         else printf("parent\n");
7       }
(gdb) break fork
Breakpoint 1 at 0x80003b8
(gdb) run
Starting program: /home/dan/src/hello/./fork 
Breakpoint 1 at 0x400177c4

Breakpoint 1, 0x400177c4 in fork ()
(gdb) return 0
Make selected stack frame return now? (y or n) y
#0  0x80004a8 in main ()
    at fork.c:5
5         if(fork()==0) printf("child\n");
(gdb) next
Single stepping until exit from function fork, 
which has no line number information.
child
7       }

5.2.4. 核心档案(Core files)

当Linux开机时,通常组态(configuration)会设定成不要产生核心档案.要是你那麽喜欢它们的话,可以用shell的builtin命令使其重新生效:就C-shell相容的shell(如tcsh)而言,会是下面这样:

% limit core unlimited
而类似Bourne shell的shell(sh,bash,zsh,pdksh)则使用下面的语法:
$ ulimit -c unlimited

如果你想要有个多才多艺(versatility)的核心档命名(core file naming)(for example, if you're trying to conduct a post-mortem using a debugger that's buggy itself) ,那麽你可以对你的核心程式(kernel)做一点小小的更动(mod).找一找fs/binfmt_aout.cfs/binfmt_elf.c档内与下列相符的程式片段(in newer kernels, you'll have to grep around a little in older ones):

        memcpy(corefile,"core.",5);
#if 0
        memcpy(corefile+5,current->comm,sizeof(current->comm));
#else
        corefile[4] = '\0';
#endif

0换成1.

5.3. 旁敲侧击(Profiling)

Profiling是用来检核一支程式中那些部份(which bits)是最常呼叫或是执行的时间最久的方法.这对程式的最佳化与找出何时时间是浪费掉的而言,是相当好的方式.你必须就你所要的时程资讯(timing information)的目的档案(object files)加上-p来编译,而且如果要让输出的档案(output files)有意义(make sense),你也会需要gprof(来自binutils套件的命令).参阅gprof的manual page,可得知其细节.

11/18/97译


The Linux GCC HOWTO中译版V0.1 : Debugging and Profiling
Previous: 移植(Porting)与编译(Compiling)程式
Next: 连结(Linking)