GDB

2.6.2 在调试器中运行一个程序

　　要最大限度的利用 gdb，需要使用 -g 这个选项来编译你的程序。如果你没有这样做，那么你只会看 到你正在调试的函数名字，而不是它的源代码。如果 gdb起动 时提示：

... (no debugging symbols found) ...

　　你就知道你的程序在编译的时候没有使用 -g 选项。

　　当 gdb 给出提示符，输入 break main。 这就是告诉调试器你对正在运行的程序中预先设置的代码没有兴趣， 并且调试器应该停在你的代码的开头。然后输入 run 来开始你的程序──这会从 预先设置的代码开始然后在调试器调用 main() 的时候就停 下来。(如果你曾迷惑 main() 是在哪里被调用的，现在应该 明白了吧！)

　　现在你可以一步一步来检查你的程序，按下 n一次就查 一行。一旦你碰见了一个函数调用，可以输入 f 从函数调用中 退出来。你可以输入 up 或 down 来快速 检查这个调用。

　　这里列出了一个简单的例子。展示了怎样用 gdb 定位一个错 误。这是我们的程序(其中有一个明显的错误)：

#include <stdio.h>

int bazz(int anint);

main() {
    int i;

    printf("This is my program\n");
    bazz(i);
    return 0;
}

int bazz(int anint) {
    printf("You gave me %d\n", anint);
    return anint;
}

　　这个程序给 i 赋值 5 并把它传递给 一个函数 bazz()，这个函数将打印出我们给出的数值。

　　我们现在编译并运行这个程序，我们会得到

% cc -g -o temp temp.c
% ./temp
This is my program
anint = 4231

　　但这并不是我们想要的！应该看看到底发生了什么！

% gdb temp
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) break main               Skip the set-up code
Breakpoint 1 at 0x160f: file temp.c, line 9.    gdb puts breakpoint at main()
(gdb) run                   Run as far as main()
Starting program: /home/james/tmp/temp      Program starts running

Breakpoint 1, main () at temp.c:9       gdb stops at main()
(gdb) n                       Go to next line
This is my program              Program prints out
(gdb) s                       step into bazz()
bazz (anint=4231) at temp.c:17          gdb displays stack frame
(gdb)

　　停住！怎么 anint 会是 4231？难道 我们没有在函数 main() 中设定为 5 吗？现在我们转到 main() 来看看。

(gdb) up                   Move up call stack
#1  0x1625 in main () at temp.c:11      gdb displays stack frame
(gdb) p i                   Show us the value of i
$1 = 4231                   gdb displays 4231

　　哦，天哪！看看这代码，我们忘了初始化 i 了。本来我们 是想的

...
main() {
    int i;

    i = 5;
    printf("This is my program\n");
...

　　但是我们忘了 i=5; 这一行。因为我们没有初始化 i，这个变量在程序运行的时候就储存了偶然在那块内存中存在的 任意值。

2.6.3 检查 core 文件

　　基本上 core 文件就是一个包含了程序崩溃时这个进程的所有信息的文件。在那 “遥远的黄金年代”，程序员不得不把 core 文件以十六进制的方式显示 出来，然后满头大汗的阅读机器码的手册，但是现在事情就简单得多了。顺便说一下， 在 FreeBSD 和其他的 4.4BSD 系统下，core 文件都叫作 progname.core 而不是简单叫 core，这样可以很清楚的表示出这个 core 文件是属于哪个 程序。

　　要检查一个 core 文件，以通常的方式起动 gdb。不要 输入 break 或者 run，而要输入

(gdb) core progname.core

　　如果你没有和 core 文件在同一个目录，首先要执行 dir /path/to/core/file。

　　你应该可以看见：

% gdb a.out
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) core a.out.core
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x7020796d.
#0  0x164a in bazz (anint=0x5) at temp.c:17
(gdb)

　　这种情况下，运行的程序叫 a.out，因此 core 文件 就叫 a.out.core。我们知道程序崩溃的原因就是函数 bazz 试图访问一块不属于它的内存。

　　有时候，能知道一个函数是怎么被调用的是非常有用处的。因为在一个复杂的 程序里面问题可能会发生在函数调用栈上面很远的地方。命令 bt 会让 gdb 输出函数调用栈的回溯追踪。

(gdb) bt
#0  0x164a in bazz (anint=0x5) at temp.c:17
#1  0xefbfd888 in end ()
#2  0x162c in main () at temp.c:11
(gdb)

　　函数 end() 在一个程序崩溃的时候将被调用；在本例 中，函数 bazz() 是从 main() 中被 调用的。

2.6.4 粘付到一个正在运行的程序

　　gdb 一个最精致的特性就是它能粘付到一个已经在运行 的程序上。当然，我们得首先假定你有足够的权限这样去做。一个常见的问题就是， 当我们在追踪一个包含子进程的程序时，如果你要追踪子进程，但是调试器只允许你 追踪父进程。

　　你要做的就是起动另一个 gdb，然后用 ps 找出子进程的进程号。然后在 gdb中执行

(gdb) attach pid

　　就可以像平时一样调试了。

　　“这很好，”你可能在想，“当我这样做了以后，子进程就 会不见了”。别怕，亲爱的读者，我们可以这样来做(参照 gdb 的 info 页)

...
if ((pid = fork()) < 0)      /* _Always_ check this */
    error();
else if (pid == 0) {        /* child */
    int PauseMode = 1;

    while (PauseMode)
        sleep(10);  /* Wait until someone attaches to us */
    ...
} else {            /* parent */
    ...