简介： 您可以用各种方法来监控运行着的用户空间程序：可以为其运行调试器并单步调试该程序，添加打印语句，或者添加工具来分析程序。本文描述了几种可以用来调试在 Linux 上运行的程序的方法。我们将回顾四种调试问题的情况，这些问题包括段错误，内存溢出和泄漏，还有挂起。

本文讨论了四种调试 Linux 程序的情况。在第 1 种情况中，我们使用了两个有内存分配问题的样本程序，使用 MEMWATCH 和 Yet Another Malloc Debugger（YAMD）工具来调试它们。在第 2 种情况中，我们使用了 Linux 中的 strace 实用程序，它能够跟踪系统调用和信号，从而找出程序发生错误的地方。在第 3 种情况中，我们使用 Linux 内核的 Oops 功能来解决程序的段错误，并向您展示如何设置内核源代码级调试器（kernel source level debugger，kgdb），以使用 GNU 调试器（GNU debugger，gdb）来解决相同的问题；kgdb 程序是使用串行连接的 Linux 内核远程 gdb。在第 4 种情况中，我们使用 Linux 上提供的魔术键控顺序（magic key sequence）来显示引发挂起问题的组件的信息。

常见调试方法

当您的程序中包含错误时，很可能在代码中某处有一个条件，您认为它为真（true），但实际上是假（false）。找出错误的过程也就是在找出错误后推翻以前一直确信为真的某个条件过程。

以下几个示例是您可能确信成立的条件的一些类型：

• 在源代码中的某处，某变量有特定的值。
• 在给定的地方，某个结构已被正确设置。
• 对于给定的 if-then-else 语句， if 部分就是被执行的路径。
• 当子例程被调用时，该例程正确地接收到了它的参数。

找出错误也就是要确定上述所有情况是否存在。如果您确信在子例程被调用时某变量应该有特定的值，那么就检查一下情况是否如此。如果您相信 if 结构会被执行，那么也检查一下情况是否如此。通常，您的假设都会是正确的，但最终您会找到与假设不符的情况。结果，您就会找出发生错误的地方。

调试是您无法逃避的任务。进行调试有很多种方法，比如将消息打印到屏幕上、使用调试器，或只是考虑程序执行的情况并仔细地揣摩问题所在。

在修正问题之前，您必须找出它的源头。举例来说，对于段错误，您需要了解段错误发生在代码的哪一行。一旦您发现了代码中出错的行，请确定该方法中变量的值、方法被调用的方式以及关于错误如何发生的详细情况。使用调试器将使找出所有这些信息变得很简单。如果没有调试器可用，您还可以使用其它的工具。（请注意，产品环境中可能并不提供调试器，而且 Linux 内核没有内建的调试器。）

本文将讨论一类通过人工检查代码不容易找到的问题，而且此类问题只在很少见的情况下存在。内存错误通常在多种情况同时存在时出现，而且您有时只能在部署程序之后才能发现内存错误。

回页首

第 1 种情况：内存调试工具

C 语言作为 Linux 系统上标准的编程语言给予了我们对动态内存分配很大的控制权。然而，这种自由可能会导致严重的内存管理问题，而这些问题可能导致程序崩溃或随时间的推移导致性能降级。

内存泄漏（即 malloc() 内存在对应的 free() 调用执行后永不被释放）和缓冲区溢出（例如对以前分配到某数组的内存进行写操作）是一些常见的问题，它们可能很难检测到。这一部分将讨论几个调试工具，它们极大地简化了检测和找出内存问题的过程。

回页首

MEMWATCH

MEMWATCH 由 Johan Lindh 编写，是一个开放源代码 C 语言内存错误检测工具，您可以自己下载它（请参阅本文后面部分的 参考资料）。只要在代码中添加一个头文件并在 gcc 语句中定义了 MEMWATCH 之后，您就可以跟踪程序中的内存泄漏和错误了。MEMWATCH 支持 ANSI C，它提供结果日志纪录，能检测双重释放（double-free）、错误释放（erroneous free）、没有释放的内存（unfreed memory）、溢出和下溢等等。

清单 1. 内存样本（test1.c）

#include <stdlib.h>
#include <stdio.h>
#include "memwatch.h"
int main(void)
{char *ptr1;char *ptr2;ptr1 = malloc(512);ptr2 = malloc(512);ptr2 = ptr1;free(ptr2);free(ptr1);
}

清单 1 中的代码将分配两个 512 字节的内存块，然后指向第一个内存块的指针被设定为指向第二个内存块。结果，第二个内存块的地址丢失，从而产生了内存泄漏。

现在我们编译清单 1 的 memwatch.c。下面是一个 makefile 示例：

test1

gcc -DMEMWATCH -DMW_STDIO test1.c memwatch
c -o test1

当您运行 test1 程序后，它会生成一个关于泄漏的内存的报告。清单 2 展示了示例 memwatch.log 输出文件。

清单 2. test1 memwatch.log 文件

  MEMWATCH 2.67 Copyright (C) 1992-1999 Johan Lindh
...
double-free: <4> test1.c(15), 0x80517b4 was freed from test1.c(14)
...
unfreed: <2> test1.c(11), 512 bytes at 0x80519e4
{FE FE FE FE FE FE FE FE FE FE FE FE ..............}
Memory usage statistics (global):N)umber of allocations made: 	2L)argest memory usage : 	1024T)otal of all alloc() calls: 	1024U)nfreed bytes totals : 	512

MEMWATCH 为您显示真正导致问题的行。如果您释放一个已经释放过的指针，它会告诉您。对于没有释放的内存也一样。日志结尾部分显示统计信息，包括泄漏了多少内存，使用了多少内存，以及总共分配了多少内存。

回页首

YAMD

YAMD 软件包由 Nate Eldredge 编写，可以查找 C 和 C++ 中动态的、与内存分配有关的问题。在撰写本文时，YAMD 的最新版本为 0.32。请下载 yamd-0.32.tar.gz（请参阅参考资料）。执行make 命令来构建程序；然后执行 make install 命令安装程序并设置工具。

一旦您下载了 YAMD 之后，请在 test1.c 上使用它。请删除 #include memwatch.h 并对 makefile 进行如下小小的修改：

使用 YAMD 的 test1

gcc -g test1.c -o test1

清单 3 展示了来自 test1 上的 YAMD 的输出。

清单 3. 使用 YAMD 的 test1 输出

YAMD version 0.32
Executable: /usr/src/test/yamd-0.32/test1
...
INFO: Normal allocation of this block
Address 0x40025e00, size 512
...
INFO: Normal allocation of this block
Address 0x40028e00, size 512
...
INFO: Normal deallocation of this block
Address 0x40025e00, size 512
...
ERROR: Multiple freeing At
free of pointer already freed
Address 0x40025e00, size 512
...
WARNING: Memory leak
Address 0x40028e00, size 512
WARNING: Total memory leaks:
1 unfreed allocations totaling 512 bytes
*** Finished at Tue ... 10:07:15 2002
Allocated a grand total of 1024 bytes 2 allocations
Average of 512 bytes per allocation
Max bytes allocated at one time: 1024
24 K alloced internally / 12 K mapped now / 8 K max
Virtual program size is 1416 K
End.

YAMD 显示我们已经释放了内存，而且存在内存泄漏。让我们在清单 4 中另一个样本程序上试试 YAMD。

清单 4. 内存代码（test2.c）

#include <stdlib.h>
#include <stdio.h>
int main(void)
{char *ptr1;char *ptr2;char *chptr;int i = 1;ptr1 = malloc(512);ptr2 = malloc(512);chptr = (char *)malloc(512);for (i; i <= 512; i++) {chptr[i] = 'S';}	ptr2 = ptr1;free(ptr2);free(ptr1);free(chptr);
}

您可以使用下面的命令来启动 YAMD：

./run-yamd /usr/src/test/test2/test2

清单 5 显示了在样本程序 test2 上使用 YAMD 得到的输出。YAMD 告诉我们在 for 循环中有“越界（out-of-bounds）”的情况。

清单 5. 使用 YAMD 的 test2 输出

Running /usr/src/test/test2/test2
Temp output to /tmp/yamd-out.1243
*********
./run-yamd: line 101: 1248 Segmentation fault (core dumped)
YAMD version 0.32
Starting run: /usr/src/test/test2/test2
Executable: /usr/src/test/test2/test2
Virtual program size is 1380 K
...
INFO: Normal allocation of this block
Address 0x40025e00, size 512
...
INFO: Normal allocation of this block
Address 0x40028e00, size 512
...
INFO: Normal allocation of this block
Address 0x4002be00, size 512
ERROR: Crash
...
Tried to write address 0x4002c000
Seems to be part of this block:
Address 0x4002be00, size 512
...
Address in question is at offset 512 (out of bounds)
Will dump core after checking heap.
Done.

MEMWATCH 和 YAMD 都是很有用的调试工具，它们的使用方法有所不同。对于 MEMWATCH，您需要添加包含文件 memwatch.h 并打开两个编译时间标记。对于链接（link）语句，YAMD 只需要-g 选项。

回页首

Electric Fence

多数 Linux 分发版包含一个 Electric Fence 包，不过您也可以选择下载它。Electric Fence 是一个由 Bruce Perens 编写的malloc() 调试库。它就在您分配内存后分配受保护的内存。如果存在 fencepost 错误（超过数组末尾运行），程序就会产生保护错误，并立即结束。通过结合 Electric Fence 和 gdb，您可以精确地跟踪到哪一行试图访问受保护内存。Electric Fence 的另一个功能就是能够检测内存泄漏。

回页首

第 2 种情况：使用 strace

strace 命令是一种强大的工具，它能够显示所有由用户空间程序发出的系统调用。strace 显示这些调用的参数并返回符号形式的值。strace 从内核接收信息，而且不需要以任何特殊的方式来构建内核。将跟踪信息发送到应用程序及内核开发者都很有用。在清单 6 中，分区的一种格式有错误，清单显示了 strace 的开头部分，内容是关于调出创建文件系统操作（mkfs ）的。strace 确定哪个调用导致问题出现。

清单 6. mkfs 上 strace 的开头部分

  execve("/sbin/mkfs.jfs", ["mkfs.jfs", "-f", "/dev/test1"], &...open("/dev/test1", O_RDWR|O_LARGEFILE) = 4stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument)write(2, "mkfs.jfs: warning - cannot setb" ..., 98mkfs.jfs: warning -cannot set blocksize on block device /dev/test1: Invalid argument )= 98stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0open("/dev/test1", O_RDONLY|O_LARGEFILE) = 5ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument)write(2, "mkfs.jfs: can\'t determine device"..., ..._exit(1)= ?

清单 6 显示 ioctl 调用导致用来格式化分区的 mkfs 程序失败。 ioctl BLKGETSIZE64 失败。（BLKGET-SIZE64 在调用ioctl 的源代码中定义。) BLKGETSIZE64 ioctl 将被添加到 Linux 中所有的设备，而在这里，逻辑卷管理器还不支持它。因此，如果BLKGETSIZE64 ioctl 调用失败，mkfs 代码将改为调用较早的ioctl 调用；这使得 mkfs 适用于逻辑卷管理器。

回页首

第 3 种情况：使用 gdb 和 Oops

您可以从命令行使用 gdb 程序（Free Software Foundation 的调试器）来找出错误，也可以从诸如 Data Display Debugger（DDD）这样的几个图形工具之一使用 gdb 程序来找出错误。您可以使用 gdb 来调试用户空间程序或 Linux 内核。这一部分只讨论从命令行运行 gdb 的情况。

使用 gdb program name 命令启动 gdb。gdb 将载入可执行程序符号并显示输入提示符，让您可以开始使用调试器。您可以通过三种方式用 gdb 查看进程：

• 使用 attach 命令开始查看一个已经运行的进程；attach 将停止进程。
  
  
• 使用 run 命令执行程序并从头开始调试程序。
  
  
• 查看已有的核心文件来确定进程终止时的状态。要查看核心文件，请用下面的命令启动 gdb。 gdb programname corefilename

  要用核心文件进行调试，您不仅需要程序的可执行文件和源文件，还需要核心文件本身。要用核心文件启动 gdb，请使用 -c 选项： gdb -c core programname

  gdb 显示哪行代码导致程序发生核心转储。

在运行程序或连接到已经运行的程序之前，请列出您觉得有错误的源代码，设置断点，然后开始调试程序。您可以使用 help 命令查看全面的 gdb 在线帮助和详细的教程。

回页首

kgdb

kgdb 程序（使用 gdb 的远程主机 Linux 内核调试器）提供了一种使用 gdb 调试 Linux 内核的机制。kgdb 程序是内核的扩展，它让您能够在远程主机上运行 gdb 时连接到运行用 kgdb 扩展的内核机器。您可以接着深入到内核中、设置断点、检查数据并进行其它操作（类似于您在应用程序上使用 gdb 的方式）。这个补丁的主要特点之一就是运行 gdb 的主机在引导过程中连接到目标机器（运行要被调试的内核）。这让您能够尽早开始调试。请注意，补丁为 Linux 内核添加了功能，所以 gdb 可以用来调试 Linux 内核。

使用 kgdb 需要两台机器：一台是开发机器，另一台是测试机器。一条串行线（空调制解调器电缆）将通过机器的串口连接它们。您希望调试的内核在测试机器上运行；gdb 在开发机器上运行。gdb 使用串行线与您要调试的内核通信。

请遵循下面的步骤来设置 kgdb 调试环境：

1. 下载您的 Linux 内核版本适用的补丁。
   
   
2. 将组件构建到内核，因为这是使用 kgdb 最简单的方法。（请注意，有两种方法可以构建多数内核组件，比如作为模块或直接构建到内核中。举例来说，日志纪录文件系统（Journaled File System，JFS）可以作为模块构建，或直接构建到内核中。通过使用 gdb 补丁，我们就可以将 JFS 直接构建到内核中。）
   
   
3. 应用内核补丁并重新构建内核。
   
   
4. 创建一个名为 .gdbinit 的文件，并将其保存在内核源文件子目录中（换句话说就是 /usr/src/linux）。文件 .gdbinit 中有下面四行代码：
   • set remotebaud 115200
   • symbol-file vmlinux
   • target remote /dev/ttyS0
   • set output-radix 16
   
   
5. 将 append=gdb 这一行添加到 lilo，lilo 是用来在引导内核时选择使用哪个内核的引导载入程序。
   • image=/boot/bzImage-2.4.17
   • label=gdb2417
   • read-only
   • root=/dev/sda8
   • append="gdb gdbttyS=1 gdb-baud=115200 nmi_watchdog=0"

清单 7 是一个脚本示例，它将您在开发机器上构建的内核和模块引入测试机器。您需要修改下面几项：

• best@sfb ：用户标识和机器名。
• /usr/src/linux-2.4.17 ：内核源代码树的目录。
• bzImage-2.4.17 ：测试机器上将引导的内核名。
• rcp 和 rsync ：必须允许它在构建内核的机器上运行。

清单 7. 引入测试机器的内核和模块的脚本

set -x
rcp best@sfb: /usr/src/linux-2.4.17/arch/i386/boot/bzImage /boot/bzImage-2.4.17
rcp best@sfb:/usr/src/linux-2.4.17/System.map /boot/System.map-2.4.17
rm -rf /lib/modules/2.4.17
rsync -a best@sfb:/lib/modules/2.4.17 /lib/modules
chown -R root /lib/modules/2.4.17
lilo

现在我们可以通过改为使用内核源代码树开始的目录来启动开发机器上的 gdb 程序了。在本示例中，内核源代码树位于 /usr/src/linux-2.4.17。输入gdb 启动程序。

如果一切正常，测试机器将在启动过程中停止。输入 gdb 命令 cont 以继续启动过程。一个常见的问题是，空调制解调器电缆可能会被连接到错误的串口。如果 gdb 不启动，将端口改为第二个串口，这会使 gdb 启动。

回页首

使用 kgdb 调试内核问题

清单 8 列出了 jfs_mount.c 文件的源代码中被修改过的代码，我们在代码中创建了一个空指针异常，从而使代码在第 109 行产生段错误。

清单 8. 修改过后的 jfs_mount.c 代码

int jfs_mount(struct super_block *sb)
{
...
int ptr; 			/* line 1 added */
jFYI(1, ("\nMount JFS\n"));
/ *
* read/validate superblock
* (initialize mount inode from the superblock)
* /
if ((rc = chkSuper(sb))) {goto errout20;}
108 	ptr=0; 			/* line 2 added */
109 	printk("%d\n",*ptr); 	/* line 3 added */

清单 9 在向文件系统发出 mount 命令之后显示一个 gdb 异常。kgdb 提供了几条命令，如显示数据结构和变量值以及显示系统中的所有任务处于什么状态、它们驻留在何处、它们在哪些地方使用了 CPU 等等。清单 9 将显示回溯跟踪为该问题提供的信息；where 命令用来执行反跟踪，它将告诉被执行的调用在代码中的什么地方停止。

清单 9. gdb 异常和反跟踪

mount -t jfs /dev/sdb /jfs
Program received signal SIGSEGV, Segmentation fault.
jfs_mount (sb=0xf78a3800) at jfs_mount.c:109
109 		printk("%d\n",*ptr);
(gdb)where
#0 jfs_mount (sb=0xf78a3800) at jfs_mount.c:109
#1 0xc01a0dbb in jfs_read_super ... at super.c:280
#2 0xc0149ff5 in get_sb_bdev ... at super.c:620
#3 0xc014a89f in do_kern_mount ... at super.c:849
#4 0xc0160e66 in do_add_mount ... at namespace.c:569
#5 0xc01610f4 in do_mount ... at namespace.c:683
#6 0xc01611ea in sys_mount ... at namespace.c:716
#7 0xc01074a7 in system_call () at af_packet.c:1891
#8 0x0 in -- ()
(gdb)

下一部分还将讨论这个相同的 JFS 段错误问题，但不设置调试器，如果您在非 kgdb 内核环境中执行清单 8 中的代码，那么它使用内核可能生成的 Oops 消息。

回页首

Oops 分析

Oops（也称 panic，慌张）消息包含系统错误的细节，如 CPU 寄存器的内容。在 Linux 中，调试系统崩溃的传统方法是分析在发生崩溃时发送到系统控制台的 Oops 消息。一旦您掌握了细节，就可以将消息发送到 ksymoops 实用程序，它将试图将代码转换为指令并将堆栈值映射到内核符号。在很多情况下，这些信息就足够您确定错误的可能原因是什么了。请注意，Oops 消息并不包括核心文件。

让我们假设系统刚刚创建了一条 Oops 消息。作为编写代码的人，您希望解决问题并确定什么导致了 Oops 消息的产生，或者您希望向显示了 Oops 消息的代码的开发者提供有关您的问题的大部分信息，从而及时地解决问题。Oops 消息是等式的一部分，但如果不通过 ksymoops 程序运行它也于事无补。下面的图显示了格式化 Oops 消息的过程。

ksymoops 需要几项内容：Oops 消息输出、来自正在运行的内核的 System.map 文件，还有 /proc/ksyms、vmlinux 和 /proc/modules。关于如何使用 ksymoops，内核源代码 /usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手册页上有完整的说明可以参考。Ksymoops 反汇编代码部分，指出发生错误的指令，并显示一个跟踪部分表明代码如何被调用。

首先，将 Oops 消息保存在一个文件中以便通过 ksymoops 实用程序运行它。清单 10 显示了由安装 JFS 文件系统的 mount 命令创建的 Oops 消息，问题是由清单 8 中添加到 JFS 安装代码的那三行代码产生的。

清单 10. ksymoops 处理后的 Oops 消息

   ksymoops 2.4.0 on i686 2.4.17. Options used
... 15:59:37 sfb1 kernel: Unable to handle kernel NULL pointer dereference at
virtual address 0000000
... 15:59:37 sfb1 kernel: c01588fc
... 15:59:37 sfb1 kernel: *pde = 0000000
... 15:59:37 sfb1 kernel: Oops: 0000
... 15:59:37 sfb1 kernel: CPU:    0
... 15:59:37 sfb1 kernel: EIP:    0010:[jfs_mount+60/704]
... 15:59:37 sfb1 kernel: Call Trace: [jfs_read_super+287/688] 
[get_sb_bdev+563/736] [do_kern_mount+189/336] [do_add_mount+35/208]
[do_page_fault+0/1264]
... 15:59:37 sfb1 kernel: Call Trace: [<c0155d4f>]...
... 15:59:37 sfb1 kernel: [<c0106e04 ...
... 15:59:37 sfb1 kernel: Code: 8b 2d 00 00 00 00 55 ...
>>EIP; c01588fc <jfs_mount+3c/2c0> <=====
...
Trace; c0106cf3 <system_call+33/40>
Code; c01588fc <jfs_mount+3c/2c0>
00000000 <_EIP>:
Code; c01588fc <jfs_mount+3c/2c0>  <=====0: 8b 2d 00 00 00 00 	mov 	0x0,%ebp    <=====
Code; c0158902 <jfs_mount+42/2c0>6:  55 			push 	%ebp

接下来，您要确定 jfs_mount 中的哪一行代码引起了这个问题。Oops 消息告诉我们问题是由位于偏移地址 3c 的指令引起的。做这件事的办法之一是对 jfs_mount.o 文件使用 objdump 实用程序，然后查看偏移地址 3c。Objdump 用来反汇编模块函数，看看您的 C 源代码会产生什么汇编指令。清单 11 显示了使用 objdump 后您将看到的内容，接着，我们查看 jfs_mount 的 C 代码，可以看到空值是第 109 行引起的。偏移地址 3c 之所以很重要，是因为 Oops 消息将该处标识为引起问题的位置。

清单 11. jfs_mount 的汇编程序清单

  109	printk("%d\n",*ptr);
objdump jfs_mount.o
jfs_mount.o: 	file format elf32-i386
Disassembly of section .text:
00000000 <jfs_mount>:0:55 			push %ebp...2c:	e8 cf 03 00 00	   call	   400 <chkSuper>31:	89 c3 	  	    	mov     %eax,%ebx33:	58		    	pop     %eax34:	85 db 	  	    	test 	%ebx,%ebx36:	0f 85 55 02 00 00 jne 	291 <jfs_mount+0x291>3c:	8b 2d 00 00 00 00 mov 	0x0,%ebp << problem line above42:	55			push 	%ebp

回页首

kdb

Linux 内核调试器（Linux kernel debugger，kdb）是 Linux 内核的补丁，它提供了一种在系统能运行时对内核内存和数据结构进行检查的办法。请注意，kdb 不需要两台机器，不过它也不允许您像 kgdb 那样进行源代码级别上的调试。您可以添加额外的命令，给出该数据结构的标识或地址，这些命令便可以格式化和显示基本的系统数据结构。目前的命令集允许您控制包括以下操作在内的内核操作：

• 处理器单步执行
• 执行到某条特定指令时停止
• 当存取（或修改）某个特定的虚拟内存位置时停止
• 当存取输入／输出地址空间中的寄存器时停止
• 对当前活动的任务和所有其它任务进行堆栈回溯跟踪（通过进程 ID）
• 对指令进行反汇编

回页首

第 4 种情况：使用魔术键控顺序进行回溯跟踪

如果在 Linux 挂起时您的键盘仍然能用，那请您使用以下方法来帮助解决挂起问题的根源。遵循这些步骤，您便可以显示当前运行的进程和所有使用魔术键控顺序的进程的回溯跟踪。

1. 您正在运行的内核必须是在启用 CONFIG_MAGIC_SYS-REQ 的情况下构建的。您还必须处在文本模式。CLTR+ALT+F1 会使您进入文本模式，CLTR+ALT+F7 会使您回到 X Windows。
2. 当在文本模式时，请按 <ALT+ScrollLock>，然后按 <Ctrl+ScrollLock>。上述魔术的击键会分别给出当前运行的进程和所有进程的堆栈跟踪。
3. 请查找 /var/log/messages。如果一切设置正确，则系统应该已经为您转换了内核的符号地址。回溯跟踪将被写到 /var/log/messages 文件中。

回页首

结束语

帮助调试 Linux 上的程序有许多不同的工具可供使用。本文讲述的工具可以帮助您解决许多编码问题。能显示内存泄漏、溢出等等的位置的工具可以解决内存管理问题，我发现 MEMWATCH 和 YAMD 很有帮助。

使用 Linux 内核补丁会使 gdb 能在 Linux 内核上工作，这对解决我工作中使用的 Linux 的文件系统方面的问题很有帮助。此外，跟踪实用程序能帮助确定在系统调用期间文件系统实用程序什么地方出了故障。下次当您要摆平 Linux 中的错误时，请试试这些工具中的某一个。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 下载 MEMWATCH。
  
  
  
  
• 请查看 Dynamic Probes 调试功能程序。
  
  
  
  
• 请阅读文章“ Linux software debugging with GDB”。（ developerWorks，2001 年 2 月）
  
  
  
  
• 请访问 IBM Linux Technology Center。
  
  
  
  
• 在 developerWorksLinux 专区可以找到 更多的 Linux 文章。
  
  

关于作者

简介： Linux 的大部分特色源自于 shell 的 GNU 调试器，也称作 gdb。gdb 可以让您查看程序的内部结构、打印变量值、设置断点，以及单步调试源代码。它是功能极其强大的工具，适用于修复程序代码中的问题。在本文中，David Seager 将尝试说明 gdb 有多棒，多实用。

编译

开始调试之前，必须用程序中的调试信息编译要调试的程序。这样，gdb 才能够调试所使用的变量、代码行和函数。如果要进行编译，请在 gcc（或 g++）下使用额外的 '-g' 选项来编译程序：

gcc -g eg.c -o eg

回页首

运行 gdb

在 shell 中，可以使用 'gdb' 命令并指定程序名作为参数来运行 gdb，例如 'gdb eg'；或者在 gdb 中，可以使用 file 命令来装入要调试的程序，例如 'file eg'。这两种方式都假设您是在包含程序的目录中执行命令。装入程序之后，可以用 gdb 命令 'run' 来启动程序。

回页首

调试会话示例

如果一切正常，程序将执行到结束，此时 gdb 将重新获得控制。但如果有错误将会怎么样？这种情况下，gdb 会获得控制并中断程序，从而可以让您检查所有事物的状态，如果运气好的话，可以找出原因。为了引发这种情况，我们将使用一个示例程序：

#include 
int wib(int no1, int no2)
{int result, diff;diff = no1 - no2;result = no1 / diff;return result;
}
int main(int argc, char *argv[])
{int value, div, result, i, total;value = 10;div = 6;total = 0;for(i = 0; i < 10; i++){result = wib(value, div);total += result;div++;value--;}printf("%d wibed by %d equals %d\n", value, div, total);return 0;
}

这个程序将运行 10 次 for 循环，使用 'wib()" 函数计算出累积值，最后打印出结果。

在您喜欢的文本编辑器中输入这个程序（要保持相同的行距），保存为 'eg1.c'，使用 'gcc -g eg1.c -o eg1' 进行编译，并用 'gdb eg1' 启动 gdb。使用 'run' 运行程序可能会产生以下消息：

Program received signal SIGFPE, Arithmetic exception.
0x80483ea in wib (no1=8, no2=8) at eg1.c:7
7         result = no1 / diff;
(gdb)

gdb 指出在程序第 7 行发生一个算术异常，通常它会打印这一行以及 wib() 函数的自变量值。要查看第 7 行前后的源代码，请使用 'list' 命令，它通常会打印 10 行。再次输入 'list'（或者按回车重复上一条命令）将列出程序的下 10 行。从 gdb 消息中可以看出，第 7 行中的除法运算出了错，程序在这一行中将变量 "no1" 除以 "diff"。

要查看变量的值，使用 gdb 'print' 命令并指定变量名。输入 'print no1' 和 'print diff'，可以相应看到 "no1" 和 "diff" 的值，结果如下：

(gdb) print no1
$5 = 8
(gdb) print diff
$2 = 0

gdb 指出 "no1" 等于 8，"diff" 等于 0。根据这些值和第 7 行中的语句，我们可以推断出算术异常是由除数为 0 的除法运算造成的。清单显示了第 6 行计算的变量 "diff"，我们可以打印 "diff" 表达式（使用 'print no1 - no2' 命令），来重新估计这个变量。gdb 告诉我们 wib 函数的这两个自变量都等于 8，于是我们要检查调用 wib() 函数的 main() 函数，以查看这是在什么时候发生的。在允许程序自然终止的同时，我们使用 'continue' 命令告诉 gdb 继续执行。

(gdb) continue
Continuing.
Program terminated with signal SIGFPE, Arithmetic exception.
The program no longer exists.

回页首

使用断点

为了查看在 main() 中发生了什么情况，可以在程序代码中的某一特定行或函数中设置断点，这样 gdb 会在遇到断点时中断执行。可以使用命令 'break main' 在进入 main() 函数时设置断点，或者可以指定其它任何感兴趣的函数名来设置断点。然而，我们只希望在调用 wib() 函数之前中断执行。输入 'list main' 将打印从 main() 函数开始的源码清单，再次按回车将显示第 21 行上的 wib() 函数调用。要在那一行上设置断点，只需输入 'break 21'。gdb 将发出以下响应：

(gdb) break 21
Breakpoint 1 at 0x8048428: file eg1.c, line 21.

以显示它已在我们请求的行上设置了 1 号断点。'run' 命令将从头重新运行程序，直到 gdb 中断为止。发生这种情况时，gdb 会生成一条消息，指出它在哪个断点上中断，以及程序运行到何处：

Breakpoint 1, main (argc=1, argv=0xbffff954) at eg1.c:21
21          result = wib(value, div);

发出 'print value' 和 'print div' 将会显示在第一次调用 wib() 时，变量分别等于 10 和 6，而 'print i' 将会显示 0。幸好，gdb 将显示所有局部变量的值，并使用 'info locals' 命令保存大量输入信息。

从以上的调查中可以看出，当 "value" 和 "div" 相等时就会出现问题，因此输入 'continue' 继续执行，直到下一次遇到 1 号断点。对于这次迭代，'info locals' 显示了 value=9 和 div=7。

与其再次继续，还不如使用 'next' 命令单步调试程序，以查看 "value" 和 "div" 是如何改变的。gdb 将响应：

(gdb) next
22          total += result;

再按两次回车将显示加法和减法表达式：

(gdb)
23          div++;
(gdb)
24          value--;

再按两次回车将显示第 21 行，wib() 调用。'info locals' 将显示目前 "div" 等于 "value"，这就意味着将发生问题。如果有兴趣，可以使用 'step' 命令（与 'next' 形成对比，'next' 将跳过函数调用）来继续执行 wib() 函数，以再次查看除法错误，然后使用 'next' 来计算 "result"。

现在已完成了调试，可以使用 'quit' 命令退出 gdb。由于程序仍在运行，这个操作会终止它，gdb 将提示您确认。

回页首

更多断点和观察点

由于我们想要知道在调用 wib() 函数之前 "value" 什么时候等于 "div"，因此在上一示例中我们在第 21 行中设置断点。我们必须继续执行两次程序才会发生这种情况，但是只要在断点上设置一个条件就可以使 gdb 只在 "value" 与 "div" 真正相等时暂停。要设置条件，可以在定义断点时指定 "break <line number> if <conditional expression>"。将 eg1 再次装入 gdb，并输入：

(gdb) break 21 if value==div
Breakpoint 1 at 0x8048428: file eg1.c, line 21.

如果已经在第 21 行中设置了断点，如 1 号断点，则可以使用 'condition' 命令来代替在断点上设置条件：

(gdb) condition 1 value==div

使用 'run' 运行 eg1.c 时，如果 "value" 等于 "div"，gdb 将中断，从而避免了在它们相等之前必须手工执行 'continue'。调试 C 程序时，断点条件可以是任何有效的 C 表达式，一定要是程序所使用语言的任意有效表达式。条件中指定的变量必须在设置了断点的行中，否则表达式就没有什么意义！

使用 'condition' 命令时，如果指定断点编号但又不指定表达式，可以将断点设置成无条件断点，例如，'condition 1' 就将 1 号断点设置成无条件断点。

要查看当前定义了什么断点及其条件，请发出命令 'info break'：

(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x08048428 in main at eg1.c:21stop only if value == divbreakpoint already hit 1 time

除了所有条件和已经遇到断点多少次之外，断点信息还在 'Enb' 列中指定了是否启用该断点。可以使用命令 'disable <breakpoint number>'、'enable <breakpoint number>' 或 'delete <breakpoint number>' 来禁用、启用和彻底删除断点，例如 'disable 1' 将阻止在 1 号断点处中断。

如果我们对 "value" 什么时候变得与 "div" 相等更感兴趣，那么可以使用另一种断点，称作监视。当指定表达式的值改变时，监视点将中断程序执行，但必须在表达式中所使用的变量在作用域中时设置监视点。要获取作用域中的 "value" 和 "div"，可以在 main 函数上设置断点，然后运行程序，当遇到 main() 断点时设置监视点。重新启动 gdb，并装入 eg1，然后输入：

(gdb) break main
Breakpoint 1 at 0x8048402: file eg1.c, line 15.
(gdb) run
...
Breakpoint 1, main (argc=1, argv=0xbffff954) at eg1.c:15
15        value = 10;

要了解 "div" 何时更改，可以使用 'watch div'，但由于要在 "div" 等于 "value" 时中断，那么应输入：

(gdb) watch div==value
Hardware watchpoint 2: div == value

如果继续执行，那么当表达式 "div==value" 的值从 0（假）变成 1（真）时，gdb 将中断：

(gdb) continue
Continuing.
Hardware watchpoint 2: div == value
Old value = 0
New value = 1
main (argc=1, argv=0xbffff954) at eg1.c:19
19        for(i = 0; i < 10; i++)

'info locals' 命令将验证 "value" 是否确实等于 "div"（再次声明，是 8）。

'info watch' 命令将列出已定义的监视点和断点（此命令等价于 'info break'），而且可以使用与断点相同的语法来启用、禁用和删除监视点。

回页首

core 文件

在 gdb 下运行程序可以使俘获错误变得更容易，但在调试器外运行的程序通常会中止而只留下一个 core 文件。gdb 可以装入 core 文件，并让您检查程序中止之前的状态。

在 gdb 外运行示例程序 eg1 将会导致核心信息转储：

$ ./eg1
Floating point exception (core dumped)

要使用 core 文件启动 gdb，在 shell 中发出命令 'gdb eg1 core' 或 'gdb eg1 -c core'。gdb 将装入 core 文件，eg1 的程序清单，显示程序是如何终止的，并显示非常类似于我们刚才在 gdb 下运行程序时看到的消息：

...
Core was generated by `./eg1'.
Program terminated with signal 8, Floating point exception.
...
#0  0x80483ea in wib (no1=8, no2=8) at eg1.c:7
7         result = no1 / diff;

此时，可以发出 'info locals'、'print'、'info args' 和 'list' 命令来查看引起除数为零的值。'info variables' 命令将打印出所有程序变量的值，但这要进行很长时间，因为 gdb 将打印 C 库和程序代码中的变量。为了更容易地查明在调用 wib() 的函数中发生了什么情况，可以使用 gdb 的堆栈命令。

回页首

堆栈跟踪

程序“调用堆栈”是当前函数之前的所有已调用函数的列表（包括当前函数）。每个函数及其变量都被分配了一个“帧”，最近调用的函数在 0 号帧中（“底部”帧）。要打印堆栈，发出命令 'bt'（'backtrace' [回溯] 的缩写）：

(gdb) bt
#0  0x80483ea in wib (no1=8, no2=8) at eg1.c:7
#1  0x8048435 in main (argc=1, argv=0xbffff9c4) at eg1.c:21

此结果显示了在 main() 的第 21 行中调用了函数 wib()（只要使用 'list 21' 就能证实这一点），而且 wib() 在 0 号帧中，main() 在 1 号帧中。由于 wib() 在 0 号帧中，那么它就是执行程序时发生算术错误的函数。

实际上，发出 'info locals' 命令时，gdb 会打印出当前帧中的局部变量，缺省情况下，这个帧中的函数就是被中断的函数（0 号帧）。可以使用命令 'frame' 打印当前帧。要查看 main 函数（在 1 号帧中）中的变量，可以发出 'frame 1' 切换到 1 号帧，然后发出 'info locals' 命令：

(gdb) frame 1
#1  0x8048435 in main (argc=1, argv=0xbffff9c4) at eg1.c:21
21          result = wib(value, div);
(gdb) info locals
value = 8
div = 8
result = 4
i = 2
total = 6

此信息显示了在第三次执行 "for" 循环时（i 等于 2）发生了错误，此时 "value" 等于 "div"。

可以通过如上所示在 'frame' 命令中明确指定号码，或者使用 'up' 命令在堆栈中上移以及 'down' 命令在堆栈中下移来切换帧。要获取有关帧的进一步信息，如它的地址和程序语言，可以使用命令 'info frame'。

gdb 堆栈命令可以在程序执行期间使用，也可以在 core 文件中使用，因此对于复杂的程序，可以在程序运行时跟踪它是如何转到函数的。

回页首

连接到其它进程

除了调试 core 文件或程序之外，gdb 还可以连接到已经运行的进程（它的程序已经过编译，并加入了调试信息），并中断该进程。只需用希望 gdb 连接的进程标识替换 core 文件名就可以执行此操作。以下是一个执行循环并睡眠的示例程序：

#include 
int main(int argc, char *argv[])
{int i;for(i = 0; i < 60; i++){sleep(1);}return 0;
}

使用 'gcc -g eg2.c -o eg2' 编译该程序并使用 './eg2 &' 运行该程序。请留意在启动该程序时在背景上打印的进程标识，在本例中是 1283：

./eg2 &
[3] 1283

启动 gdb 并指定进程标识，在我举的这个例子中是 'gdb eg2 1283'。gdb 会查找一个叫作 "1283" 的 core 文件。如果没有找到，那么只要进程 1283 正在运行（在本例中可能在 sleep() 中），gdb 就会连接并中断该进程：

...
/home/seager/gdb/1283: No such file or directory.
Attaching to program: /home/seager/gdb/eg2, Pid 1283
...
0x400a87f1 in __libc_nanosleep () from /lib/libc.so.6
(gdb)

此时，可以发出所有常用 gdb 命令。可以使用 'backtrace' 来查看当前位置与 main() 的相对关系，以及 mian() 的帧号是什么，然后切换到 main() 所在的帧，查看已经在 "for" 循环中运行了多少次：

(gdb) backtrace
#0  0x400a87f1 in __libc_nanosleep () from /lib/libc.so.6
#1  0x400a877d in __sleep (seconds=1) at ../sysdeps/unix/sysv/linux/sleep.c:78
#2  0x80483ef in main (argc=1, argv=0xbffff9c4) at eg2.c:7
(gdb) frame 2
#2  0x80483ef in main (argc=1, argv=0xbffff9c4) at eg2.c:7
7           sleep(1);
(gdb) print i
$1 = 50

如果已经完成了对程序的修改，可以 'detach' 命令继续执行程序，或者 'kill' 命令杀死进程。还可以首先使用 'file eg2' 装入文件，然后发出 'attach 1283' 命令连接到进程标识 1283 下的 eg2。

回页首

其它小技巧

gdb 可以让您通过使用 shell 命令在不退出调试环境的情况下运行 shell 命令，调用形式是 'shell [commandline]'，这有助于在调试时更改源代码。

最后，在程序运行时，可以使用 'set ' 命令修改变量的值。在 gdb 下再次运行 eg1，使用命令 'break 7 if diff==0' 在第 7 行（将在此处计算结果）设置条件断点，然后运行程序。当 gdb 中断执行时，可以将 "diff" 设置成非零值，使程序继续运行直至结束：

Breakpoint 1, wib (no1=8, no2=8) at eg1.c:7
7         result = no1 / diff;
(gdb) print diff
$1 = 0
(gdb) set diff=1
(gdb) continue
Continuing.
0 wibed by 16 equals 10
Program exited normally.

回页首

结束语

GNU 调试器是所有程序员工具库中的一个功能非常强大的工具。在本文中，我只介绍了 gdb 的一小部分功能。要了解更多知识，建议您阅读 GNU 调试器手册。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• GNU 调试器手册
  
  
• 调试会话示例的 源代码。
  
  
• 连接示例的 源代码。
  
  

关于作者

gdb （GNU 调试器）: 基础

最后，set args 为程序设置命令行参数。您也可以在执行 run 时指定命令行参数，但是 set args 将使参数在 run 的多次执行中都有效。

gdb Post Mortem

当程序意外地终止时，内核会尝试产生一个核心文件，以图判断发生了什么错误。然而，核心文件通常不是在默认设置值下产生的。这可以使用 ulimit 命令来改变。ulimit -c unlimited 帮助确保您获得应用程序的完整核心文件。

虽然核心文件当前仅提供多线程应用程序中的有限的值，不过 2.5 版的开发内核已开始处理这个问题。预计 2.6 版的内核中会提供一些理想的线程改进。

图 2突出显示了一系列便利的 post mortem 命令。图 3简要显示了一个核心程序的完整运行过程。同样，我们使用了 simple 程序。 但不是手动加载程序和核心文件，而是从命令行调入：

gdb simple core

在加载符号之后，gdb 将指出程序在何处终止。注意当前帧 #0 包含前一节中计算的地址。gdb 将在 31 位系统上截去高位，仅显示指令地址。 还要注意帧 #1 包含 gpr14 中的返回地址。

接着往下看，i f 提供了关于当前堆栈帧的信息。在堆栈帧中往上移到 main，这就是我们离开该帧的地方（即调用 memcpy 的地方）。简单的 i locals 提供了传递给 memcpy 的变量的值，其中一个变量 boink.boik 的值为 0x0。使用 ptype 来检查变量类型，这样将确认它是一个整型指针，并且如果目的是为了拷贝内容到其中，它就不应该是 0x0。最后一个选项是使用 print，通过一个星号（*）来解除指针引用，以便接收值。

回页首

处理优化过的代码

先前，我曾提到当您在源代码级调试优化过的代码时，gdb 可能变得有点棘手。编译器优化一些代码的执行顺序以最大化性能。 图4显示了这样一个例子。您可以看到行号如何从 32 切换到 30 然后又切换回 32。

如何处理这种情况呢？使用 si 和 ni（next instruction；它类似 si，但是会跳过子例程调用）将非常有帮助。 在这个层次上，很好理解 zArchitecture 是有所帮助的。

图 5显示了为调试而对程序进行的设置。首先在 main()的地址处设置一个断点，然后设置一个 display。display 是一个表达式，它在每次代码停止执行时打印有关信息。在此例中，display 被设置为显示当前指令地址处的指令。/i 是打印为反汇编代码的格式，而当前指令指针在值/寄存器（value/register）$pswa 中。

单步调试代码，可以明显看出每条机器指令都与一行 c 代码相关联。 前四行与第 27 行（即函数 main 的开头）相关联。 前四行是典型的函数引入操作，它们保存寄存器、堆栈指针并调整堆栈。当关联的行号变为32 时，我们就设置好了对 do_one_thing() 的函数调用。

当 display 在工作时，它显示 x /i 作为实际数据显示之前的命令。x 是检查内存的命令。/i 是以指令格式来格式化；/x 将以 16 进制格式来格式化；而 /a 将以 16 进制来格式化。然而，您应该在尽可能的地方把该值看作是地址，并解析符号名称。

当在指令级工作时，设置一些显示可能是有所帮助的。您可以将所有 display 命令放在一个文件中，并在命令行上使用 -x 选项来指定它。 图 6包含了工作在汇编程序级时通常使用的 display 命令。

这个命令打印全部 PSW 值、所有通用寄存器和从当前指令地址开始的下 10 行机器代码。 图 7显示了当我们在 main() 处中断时的结果。可以看到，在其中一些寄存器所指向的地方，/a 格式解析是如何使得理解正在发生的事情更加容易的。

回页首

结束语

对于一些可用于 Linux 应用程序调试的基本工具以及调试过程本身，本文中的信息应该为您提供了有用的入门信息。

关于作者

target: dependenciesinstructions

make: "Makefile" line 2: Need an operator
make: Fatal errors encountered -- cannot continue

Makefile::2: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

default: all

all: hello goodbye fibonacci

build: clean all install

$ make hello
cc -O2   -o hello hello.c

.c.o:cc $(CFLAGS) -c $<

all:for i in $(ALLDIRS) ; \do      ( cd $$i ; $(MAKE) all ) ; \done

all:@echo "Beginning build at:"@date@echo "--------"

echo "Beginning build at:"
Beginning build at:
date
Sun Jun 18 01:13:21 CDT 2006
echo "--------"
--------

Peter Seebach 有多年使用计算机的经验，已经逐渐变成了计算机高手。但是他仍然不知道为什么需要如此频繁地清理鼠标。

简介： 本文将首先介绍 Linux 内核上的一些内核代码监视和错误跟踪技术，这些调试和跟踪方法因所要求的使用环境和使用方法而各有不同，然后重点介绍三种 Linux 内核的源代码级的调试方法。

调试是软件开发过程中一个必不可少的环节，在 Linux 内核开发的过程中也不可避免地会面对如何调试内核的问题。但是，Linux 系统的开发者出于保证内核代码正确性的考虑，不愿意在 Linux 内核源代码树中加入一个调试器。他们认为内核中的调试器会误导开发者，从而引入不良的修正[1]。所以对 Linux 内核进行调试一直是个令内核程序员感到棘手的问题，调试工作的艰苦性是内核级的开发区别于用户级开发的一个显著特点。

尽管缺乏一种内置的调试内核的有效方法，但是 Linux 系统在内核发展的过程中也逐渐形成了一些监视内核代码和错误跟踪的技术。同时，许多的补丁程序应运而生，它们为标准内核附加了内核调试的支持。尽管这些补丁有些并不被 Linux 官方组织认可，但他们确实功能完善，十分强大。调试内核问题时，利用这些工具与方法跟踪内核执行情况，并查看其内存和数据结构将是非常有用的。

本文将首先介绍 Linux 内核上的一些内核代码监视和错误跟踪技术，这些调试和跟踪方法因所要求的使用环境和使用方法而各有不同，然后重点介绍三种 Linux 内核的源代码级的调试方法。

1. Linux 系统内核级软件的调试技术

printk() 是调试内核代码时最常用的一种技术。在内核代码中的特定位置加入printk() 调试调用，可以直接把所关心的信息打打印到屏幕上，从而可以观察程序的执行路径和所关心的变量、指针等信息。 Linux 内核调试器（Linux kernel debugger，kdb）是 Linux 内核的补丁，它提供了一种在系统能运行时对内核内存和数据结构进行检查的办法。Oops、KDB在文章掌握Linux 调试技术有详细介绍，大家可以参考。 Kprobes 提供了一个强行进入任何内核例程，并从中断处理器无干扰地收集信息的接口。使用 Kprobes 可以轻松地收集处理器寄存器和全局数据结构等调试信息，而无需对Linux内核频繁编译和启动，具体使用方法，请参考使用 Kprobes 调试内核。

以上介绍了进行Linux内核调试和跟踪时的常用技术和方法。当然，内核调试与跟踪的方法还不止以上提到的这些。这些调试技术的一个共同的特点在于，他们都不能提供源代码级的有效的内核调试手段，有些只能称之为错误跟踪技术，因此这些方法都只能提供有限的调试能力。下面将介绍三种实用的源代码级的内核调试方法。

回页首

2. 使用KGDB构建Linux内核调试环境

kgdb提供了一种使用 gdb调试 Linux 内核的机制。使用KGDB可以象调试普通的应用程序那样，在内核中进行设置断点、检查变量值、单步跟踪程序运行等操作。使用KGDB调试时需要两台机器，一台作为开发机（Development Machine）,另一台作为目标机（Target Machine），两台机器之间通过串口或者以太网口相连。串口连接线是一根RS-232接口的电缆，在其内部两端的第2脚（TXD）与第3脚（RXD）交叉相连，第7脚（接地脚）直接相连。调试过程中，被调试的内核运行在目标机上，gdb调试器运行在开发机上。

目前，kgdb发布支持i386、x86_64、32-bit PPC、SPARC等几种体系结构的调试器。有关kgdb补丁的下载地址见参考资料[4]。

2．1 kgdb的调试原理

安装kgdb调试环境需要为Linux内核应用kgdb补丁，补丁实现的gdb远程调试所需要的功能包括命令处理、陷阱处理及串口通讯3个主要的部分。kgdb补丁的主要作用是在Linux内核中添加了一个调试Stub。调试Stub是Linux内核中的一小段代码，提供了运行gdb的开发机和所调试内核之间的一个媒介。gdb和调试stub之间通过gdb串行协议进行通讯。gdb串行协议是一种基于消息的ASCII码协议，包含了各种调试命令。当设置断点时，kgdb负责在设置断点的指令前增加一条trap指令，当执行到断点时控制权就转移到调试stub中去。此时，调试stub的任务就是使用远程串行通信协议将当前环境传送给gdb，然后从gdb处接受命令。gdb命令告诉stub下一步该做什么，当stub收到继续执行的命令时，将恢复程序的运行环境，把对CPU的控制权重新交还给内核。

2．2 Kgdb的安装与设置

下面我们将以Linux 2.6.7内核为例详细介绍kgdb调试环境的建立过程。

2.2.1软硬件准备

以下软硬件配置取自笔者进行试验的系统配置情况：

kgdb补丁的版本遵循如下命名模式：Linux-A-kgdb-B，其中A表示Linux的内核版本号，B为kgdb的版本号。以试验使用的kgdb补丁为例，linux内核的版本为linux-2.6.7，补丁版本为kgdb-2.2。

物理连接好串口线后，使用以下命令来测试两台机器之间串口连接情况，stty命令可以对串口参数进行设置：

在development机上执行：

stty ispeed 115200 ospeed 115200 -F /dev/ttyS0

在target机上执行：

stty ispeed 115200 ospeed 115200 -F /dev/ttyS0

在developement机上执行：

echo hello > /dev/ttyS0

在target机上执行：

cat /dev/ttyS0

如果串口连接没问题的话在将在target机的屏幕上显示"hello"。

2．2．2 安装与配置

下面我们需要应用kgdb补丁到Linux内核，设置内核选项并编译内核。这方面的资料相对较少，笔者这里给出详细的介绍。下面的工作在开发机（developement）上进行，以上面介绍的试验环境为例，某些具体步骤在实际的环境中可能要做适当的改动：

I、内核的配置与编译

[root@lisl tmp]# tar -jxvf linux-2.6.7.tar.bz2
[root@lisl tmp]#tar -jxvf linux-2.6.7-kgdb-2.2.tar.tar
[root@lisl tmp]#cd inux-2.6.7

请参照目录补丁包中文件README给出的说明，执行对应体系结构的补丁程序。由于试验在i386体系结构上完成，所以只需要安装一下补丁：core-lite.patch、i386-lite.patch、8250.patch、eth.patch、core.patch、i386.patch。应用补丁文件时，请遵循kgdb软件包内series文件所指定的顺序，否则可能会带来预想不到的问题。eth.patch文件是选择以太网口作为调试的连接端口时需要运用的补丁

。

应用补丁的命令如下所示：

[root@lisl tmp]#patch -p1 <../linux-2.6.7-kgdb-2.2/core-lite.patch 

如果内核正确，那么应用补丁时应该不会出现任何问题（不会产生*.rej文件）。为Linux内核添加了补丁之后，需要进行内核的配置。内核的配置可以按照你的习惯选择配置Linux内核的任意一种方式。

[root@lisl tmp]#make menuconfig

在内核配置菜单的Kernel hacking选项中选择kgdb调试项，例如：

  [*] KGDB: kernel debugging with remote gdbMethod for KGDB communication (KGDB: On generic serial port (8250))  --->  [*] KGDB: Thread analysis [*] KGDB: Console messages through gdb
[root@lisl tmp]#make

编译内核之前请注意Linux目录下Makefile中的优化选项，默认的Linux内核的编译都以-O2的优化级别进行。在这个优化级别之下，编译器要对内核中的某些代码的执行顺序进行改动，所以在调试时会出现程序运行与代码顺序不一致的情况。可以把Makefile中的-O2选项改为-O,但不可去掉-O，否则编译会出问题。为了使编译后的内核带有调试信息，注意在编译内核的时候需要加上-g选项。

不过，当选择"Kernel debugging->Compile the kernel with debug info"选项后配置系统将自动打开调试选项。另外，选择"kernel debugging with remote gdb"后，配置系统将自动打开"Compile the kernel with debug info"选项。

内核编译完成后，使用scp命令进行将相关文件拷贝到target机上(当然也可以使用其它的网络工具，如rcp)。

[root@lisl tmp]#scp arch/i386/boot/bzImage root@192.168.6.13:/boot/vmlinuz-2.6.7-kgdb
[root@lisl tmp]#scp System.map root@192.168.6.13:/boot/System.map-2.6.7-kgdb

如果系统启动使所需要的某些设备驱动没有编译进内核的情况下，那么还需要执行如下操作：

[root@lisl tmp]#mkinitrd /boot/initrd-2.6.7-kgdb 2.6.7
[root@lisl tmp]#scp initrd-2.6.7-kgdb root@192.168.6.13:/boot/ initrd-2.6.7-kgdb

II、kgdb的启动

在将编译出的内核拷贝的到target机器之后，需要配置系统引导程序，加入内核的启动选项。以下是kgdb内核引导参数的说明：

如表中所述，在kgdb 2.0版本之后内核的引导参数已经与以前的版本有所不同。使用grub引导程序时，直接将kgdb参数作为内核vmlinuz的引导参数。下面给出引导器的配置示例。

title 2.6.7 kgdb
root (hd0,0)
kernel /boot/vmlinuz-2.6.7-kgdb ro root=/dev/hda1 kgdbwait kgdb8250=1,115200

在使用lilo作为引导程序时，需要把kgdb参放在由append修饰的语句中。下面给出使用lilo作为引导器时的配置示例。

image=/boot/vmlinuz-2.6.7-kgdb
label=kgdbread-onlyroot=/dev/hda3
append="gdb gdbttyS=1 gdbbaud=115200"

保存好以上配置后重新启动计算机，选择启动带调试信息的内核，内核将在短暂的运行后在创建init内核线程之前停下来，打印出以下信息，并等待开发机的连接。

Waiting for connection from remote gdb...

在开发机上执行：

gdb
file vmlinux
set remotebaud 115200
target remote /dev/ttyS0

其中vmlinux是指向源代码目录下编译出来的Linux内核文件的链接，它是没有经过压缩的内核文件，gdb程序从该文件中得到各种符号地址信息。

这样，就与目标机上的kgdb调试接口建立了联系。一旦建立联接之后，对Linux内的调试工作与对普通的运用程序的调试就没有什么区别了。任何时候都可以通过键入ctrl+c打断目标机的执行，进行具体的调试工作。

在kgdb 2.0之前的版本中，编译内核后在arch/i386/kernel目录下还会生成可执行文件gdbstart。将该文件拷贝到target机器的/boot目录下，此时无需更改内核的启动配置文件，直接使用命令：

[root@lisl boot]#gdbstart -s 115200 -t /dev/ttyS0

可以在KGDB内核引导启动完成后建立开发机与目标机之间的调试联系。

2．2．3 通过网络接口进行调试

kgdb也支持使用以太网接口作为调试器的连接端口。在对Linux内核应用补丁包时，需应用eth.patch补丁文件。配置内核时在Kernel hacking中选择kgdb调试项，配置kgdb调试端口为以太网接口，例如：

[*]KGDB: kernel debugging with remote gdb
Method for KGDB communication (KGDB: On ethernet)  ---> 
( ) KGDB: On generic serial port (8250)
(X) KGDB: On ethernet

另外使用eth0网口作为调试端口时，grub.list的配置如下：

title 2.6.7 kgdb
root (hd0,0)
kernel /boot/vmlinuz-2.6.7-kgdb ro root=/dev/hda1 kgdbwait kgdboe=@192.168.
5.13/,@192.168. 6.13/ 

其他的过程与使用串口作为连接端口时的设置过程相同。

注意：尽管可以使用以太网口作为kgdb的调试端口，使用串口作为连接端口更加简单易行，kgdb项目组推荐使用串口作为调试端口。

2．2．4 模块的调试方法

内核可加载模块的调试具有其特殊性。由于内核模块中各段的地址是在模块加载进内核的时候才最终确定的，所以develop机的gdb无法得到各种符号地址信息。所以，使用kgdb调试模块所需要解决的一个问题是，需要通过某种方法获得可加载模块的最终加载地址信息，并把这些信息加入到gdb环境中。

I、在Linux 2.4内核中的内核模块调试方法

在Linux2.4.x内核中，可以使用insmod -m命令输出模块的加载信息，例如：

[root@lisl tmp]# insmod -m hello.ko >modaddr

查看模块加载信息文件modaddr如下：

.this           00000060  c88d8000  2**2
.text           00000035  c88d8060  2**2
.rodata         00000069  c88d80a0  2**5
……
.data           00000000  c88d833c  2**2
.bss            00000000  c88d833c  2**2
……

在这些信息中，我们关心的只有4个段的地址:.text、.rodata、.data、.bss。在development机上将以上地址信息加入到gdb中,这样就可以进行模块功能的测试了。

(gdb) Add-symbol-file hello.o 0xc88d8060 -s .data 0xc88d80a0 -s 
.rodata 0xc88d80a0 -s .bss 0x c88d833c

这种方法也存在一定的不足，它不能调试模块初始化的代码，因为此时模块初始化代码已经执行过了。而如果不执行模块的加载又无法获得模块插入地址，更不可能在模块初始化之前设置断点了。对于这种调试要求可以采用以下替代方法。

在target机上用上述方法得到模块加载的地址信息，然后再用rmmod卸载模块。在development机上将得到的模块地址信息导入到gdb环境中，在内核代码的调用初始化代码之前设置断点。这样，在target机上再次插入模块时，代码将在执行模块初始化之前停下来，这样就可以使用gdb命令调试模块初始化代码了。

另外一种调试模块初始化函数的方法是：当插入内核模块时，内核模块机制将调用函数sys_init_module(kernel/modle.c)执行对内核模块的初始化，该函数将调用所插入模块的初始化函数。程序代码片断如下：

……	……if (mod->init != NULL)ret = mod->init();
……	……

在该语句上设置断点，也能在执行模块初始化之前停下来。

II、在Linux 2.6.x内核中的内核模块调试方法

Linux 2.6之后的内核中，由于module-init-tools工具的更改，insmod命令不再支持-m参数，只有采取其他的方法来获取模块加载到内核的地址。通过分析ELF文件格式，我们知道程序中各段的意义如下：

.text（代码段）：用来存放可执行文件的操作指令，也就是说是它是可执行程序在内存种的镜像。

.data（数据段）：数据段用来存放可执行文件中已初始化全局变量，也就是存放程序静态分配的变量和全局变量。

.bss（BSS段）：BSS段包含了程序中未初始化全局变量，在内存中 bss段全部置零。

.rodata（只读段）：该段保存着只读数据，在进程映象中构造不可写的段。

通过在模块初始化函数中放置一下代码，我们可以很容易地获得模块加载到内存中的地址。

……
int bss_var;
static int hello_init(void)
{
printk(KERN_ALERT "Text location .text(Code Segment):%p\n",hello_init);
static int data_var=0;
printk(KERN_ALERT "Data Location .data(Data Segment):%p\n",&data_var);
printk(KERN_ALERT "BSS Location: .bss(BSS Segment):%p\n",&bss_var);
……
}
Module_init(hello_init);

这里，通过在模块的初始化函数中添加一段简单的程序，使模块在加载时打印出在内核中的加载地址。.rodata段的地址可以通过执行命令readelf -e hello.ko，取得.rodata在文件中的偏移量并加上段的align值得出。

为了使读者能够更好地进行模块的调试，kgdb项目还发布了一些脚本程序能够自动探测模块的插入并自动更新gdb中模块的符号信息。这些脚本程序的工作原理与前面解释的工作过程相似，更多的信息请阅读参考资料[4]。

2．2．5 硬件断点

kgdb提供对硬件调试寄存器的支持。在kgdb中可以设置三种硬件断点：执行断点（Execution Breakpoint）、写断点（Write Breakpoint）、访问断点（Access Breakpoint）但不支持I/O访问的断点。目前，kgdb对硬件断点的支持是通过宏来实现的，最多可以设置4个硬件断点，这些宏的用法如下：

在有些情况下，硬件断点的使用对于内核的调试是非常方便的。有关硬件断点的定义和具体的使用说明见参考资料[4]

。

2．3．在VMware中搭建调试环境

kgdb调试环境需要使用两台微机分别充当development机和target机，使用VMware后我们只使用一台计算机就可以顺利完成kgdb调试环境的搭建。以windows下的环境为例，创建两台虚拟机，一台作为开发机，一台作为目标机。

2．3．1虚拟机之间的串口连接

虚拟机中的串口连接可以采用两种方法。一种是指定虚拟机的串口连接到实际的COM上，例如开发机连接到COM1，目标机连接到COM2，然后把两个串口通过串口线相连接。另一种更为简便的方法是：在较高一些版本的VMware中都支持把串口映射到命名管道，把两个虚拟机的串口映射到同一个命名管道。例如，在两个虚拟机中都选定同一个命名管道\\.\pipe\com_1,指定target机的COM口为server端，并选择"The other end is a virtual machine"属性；指定development机的COM口端为client端，同样指定COM口的"The other end is a virtual machine"属性。对于IO mode属性，在target上选中"Yield CPU on poll"复选择框，development机不选。这样，可以无需附加任何硬件，利用虚拟机就可以搭建kgdb调试环境。即降低了使用kgdb进行调试的硬件要求，也简化了建立调试环境的过程。

2．3．2 VMware的使用技巧

VMware虚拟机是比较占用资源的，尤其是象上面那样在Windows中使用两台虚拟机。因此，最好为系统配备512M以上的内存，每台虚拟机至少分配128M的内存。这样的硬件要求，对目前主流配置的PC而言并不是过高的要求。出于系统性能的考虑，在VMware中尽量使用字符界面进行调试工作。同时，Linux系统默认情况下开启了sshd服务，建议使用SecureCRT登陆到Linux进行操作，这样可以有较好的用户使用界面。

2．3．3 在Linux下的虚拟机中使用kgdb

对于在Linux下面使用VMware虚拟机的情况，笔者没有做过实际的探索。从原理上而言，只需要在Linux下只要创建一台虚拟机作为target机，开发机的工作可以在实际的Linux环境中进行，搭建调试环境的过程与上面所述的过程类似。由于只需要创建一台虚拟机，所以使用Linux下的虚拟机搭建kgdb调试环境对系统性能的要求较低。（vmware已经推出了Linux下的版本）还可以在development机上配合使用一些其他的调试工具，例如功能更强大的cgdb、图形界面的DDD调试器等，以方便内核的调试工作。

2．4 kgdb的一些特点和不足

使用kgdb作为内核调试环境最大的不足在于对kgdb硬件环境的要求较高，必须使用两台计算机分别作为target和development机。尽管使用虚拟机的方法可以只用一台PC即能搭建调试环境，但是对系统其他方面的性能也提出了一定的要求，同时也增加了搭建调试环境时复杂程度。另外，kgdb内核的编译、配置也比较复杂，需要一定的技巧，笔者当时做的时候也是费了很多周折。当调试过程结束后时，还需要重新制作所要发布的内核。使用kgdb并不能进行全程调试，也就是说kgdb并不能用于调试系统一开始的初始化引导过程。

不过，kgdb是一个不错的内核调试工具，使用它可以进行对内核的全面调试，甚至可以调试内核的中断处理程序。如果在一些图形化的开发工具的帮助下，对内核的调试将更方便。

回页首

3. 使用SkyEye构建Linux内核调试环境

SkyEye是一个开源软件项目（OPenSource Software）,SkyEye项目的目标是在通用的Linux和Windows平台上模拟常见的嵌入式计算机系统。SkyEye实现了一个指令级的硬件模拟平台，可以模拟多种嵌入式开发板，支持多种CPU指令集。SkyEye 的核心是 GNU 的 gdb 项目，它把gdb和 ARM Simulator很好地结合在了一起。加入ARMulator 的功能之后，它就可以来仿真嵌入式开发板，在它上面不仅可以调试硬件驱动，还可以调试操作系统。Skyeye项目目前已经在嵌入式系统开发领域得到了很大的推广。

3．1 SkyEye的安装和μcLinux内核编译

3．1.1 SkyEye的安装

SkyEye的安装不是本文要介绍的重点，目前已经有大量的资料对此进行了介绍。有关SkyEye的安装与使用的内容请查阅参考资料[11]。由于skyeye面目主要用于嵌入式系统领域，所以在skyeye上经常使用的是μcLinux系统，当然使用Linux作为skyeye上运行的系统也是可以的。由于介绍μcLinux 2.6在skyeye上编译的相关资料并不多，所以下面进行详细介绍。

3．1.2 μcLinux 2.6.x的编译

要在SkyEye中调试操作系统内核，首先必须使被调试内核能在SkyEye所模拟的开发板上正确运行。因此，正确编译待调试操作系统内核并配置SkyEye是进行内核调试的第一步。下面我们以SkyEye模拟基于Atmel AT91X40的开发板，并运行μcLinux 2.6为例介绍SkyEye的具体调试方法。

I、安装交叉编译环境

先安装交叉编译器。尽管在一些资料中说明使用工具链arm-elf-tools-20040427.sh ,但是由于arm-elf-xxx与arm-linux-xxx对宏及链接处理的不同，经验证明使用arm-elf-xxx工具链在链接vmlinux的最后阶段将会出错。所以这里我们使用的交叉编译工具链是：arm-uclinux-tools-base-gcc3.4.0-20040713.sh，关于该交叉编译工具链的下载地址请参见[6]。注意以下步骤最好用root用户来执行。

[root@lisl tmp]#chmod +x  arm-uclinux-tools-base-gcc3.4.0-20040713.sh
[root@lisl tmp]#./arm-uclinux-tools-base-gcc3.4.0-20040713.sh

安装交叉编译工具链之后，请确保工具链安装路径存在于系统PATH变量中。

II、制作μcLinux内核

得到μcLinux发布包的一个最容易的方法是直接访问uClinux.org站点[7]。该站点发布的内核版本可能不是最新的，但你能找到一个最新的μcLinux补丁以及找一个对应的Linux内核版本来制作一个最新的μcLinux内核。这里，将使用这种方法来制作最新的μcLinux内核。目前（笔者记录编写此文章时），所能得到的发布包的最新版本是uClinux-dist.20041215.tar.gz。

下载uClinux-dist.20041215.tar.gz，文件的下载地址请参见[7]。

下载linux-2.6.9-hsc0.patch.gz，文件的下载地址请参见[8]。

下载linux-2.6.9.tar.bz2，文件的下载地址请参见[9]。

现在我们得到了整个的linux-2.6.9源代码，以及所需的内核补丁。请准备一个有2GB空间的目录里来完成以下制作μcLinux内核的过程。

[root@lisl tmp]# tar -jxvf uClinux-dist-20041215.tar.bz2
[root@lisl uClinux-dist]# tar -jxvf  linux-2.6.9.tar.bz2
[root@lisl uClinux-dist]# gzip -dc linux-2.6.9-hsc0.patch.gz | patch -p0 

或者使用：

[root@lisl uClinux-dist]# gunzip linux-2.6.9-hsc0.patch.gz 
[root@lisl uClinux-dist]patch -p0 < linux-2.6.9-hsc0.patch

执行以上过程后，将在linux-2.6.9/arch目录下生成一个补丁目录－armnommu。删除原来μcLinux目录里的linux-2.6.x(即那个linux-2.6.9-uc0)，并将我们打好补丁的Linux内核目录更名为linux-2.6.x。

[root@lisl uClinux-dist]# rm -rf linux-2.6.x/
[root@lisl uClinux-dist]# mv linux-2.6.9 linux-2.6.x

III、配置和编译μcLinux内核

因为只是出于调试μcLinux内核的目的，这里没有生成uClibc库文件及romfs.img文件。在发布μcLinux时，已经预置了某些常用嵌入式开发板的配置文件，因此这里直接使用这些配置文件，过程如下：

[root@lisl uClinux-dist]# cd linux-2.6.x
[root@lisl linux-2.6.x]#make ARCH=armnommu CROSS_COMPILE=arm-uclinux- atmel_
deconfig

atmel_deconfig文件是μcLinux发布时提供的一个配置文件，存放于目录linux-2.6.x /arch/armnommu/configs/中。

[root@lisl linux-2.6.x]#make ARCH=armnommu CROSS_COMPILE=arm-uclinux-
oldconfig

下面编译配置好的内核：

[root@lisl linux-2.6.x]# make ARCH=armnommu CROSS_COMPILE=arm-uclinux- v=1

一般情况下，编译将顺利结束并在Linux-2.6.x/目录下生成未经压缩的μcLinux内核文件vmlinux。需要注意的是为了调试μcLinux内核，需要打开内核编译的调试选项-g，使编译后的内核带有调试信息。打开编译选项的方法可以选择：

"Kernel debugging->Compile the kernel with debug info"后将自动打开调试选项。也可以直接修改linux-2.6.x目录下的Makefile文件，为其打开调试开关。方法如下：。

CFLAGS  += -g 

最容易出现的问题是找不到arm-uclinux-gcc命令的错误，主要原因是PATH变量中没有包含arm-uclinux-gcc命令所在目录。在arm-linux-gcc的缺省安装情况下，它的安装目录是/root/bin/arm-linux-tool/，使用以下命令将路径加到PATH环境变量中。

Export PATH＝$PATH:/root/bin/arm-linux-tool/bin

IV、根文件系统的制作

Linux内核在启动的时的最后操作之一是加载根文件系统。根文件系统中存放了嵌入式系统使用的所有应用程序、库文件及其他一些需要用到的服务。出于文章篇幅的考虑，这里不打算介绍根文件系统的制作方法，读者可以查阅一些其他的相关资料。值得注意的是，由配置文件skyeye.conf指定了装载到内核中的根文件系统。

3．2 使用SkyEye调试

编译完μcLinux内核后，就可以在SkyEye中调试该ELF执行文件格式的内核了。前面已经说过利用SkyEye调试内核与使用gdb调试运用程序的方法相同。

需要提醒读者的是，SkyEye的配置文件－skyeye.conf记录了模拟的硬件配置和模拟执行行为。该配置文件是SkyEye系统中一个及其重要的文件，很多错误和异常情况的发生都和该文件有关。在安装配置SkyEye出错时，请首先检查该配置文件然后再进行其他的工作。此时，所有的准备工作已经完成，就可以进行内核的调试工作了。

3．3使用SkyEye调试内核的特点和不足

在SkyEye中可以进行对Linux系统内核的全程调试。由于SkyEye目前主要支持基于ARM内核的CPU，因此一般而言需要使用交叉编译工具编译待调试的Linux系统内核。另外，制作SkyEye中使用的内核编译、配置过程比较复杂、繁琐。不过，当调试过程结束后无需重新制作所要发布的内核。

SkyEye只是对系统硬件进行了一定程度上的模拟，所以在SkyEye与真实硬件环境相比较而言还是有一定的差距，这对一些与硬件紧密相关的调试可能会有一定的影响，例如驱动程序的调试。不过对于大部分软件的调试，SkyEye已经提供了精度足够的模拟了。

SkyEye的下一个目标是和eclipse结合，有了图形界面，能为调试和查看源码提供一些方便。

回页首

4. 使用UML调试Linux内核

User-mode Linux（UML）简单说来就是在Linux内运行的Linux。该项目是使Linux内核成为一个运行在 Linux 系统之上单独的、用户空间的进程。UML并不是运行在某种新的硬件体系结构之上，而是运行在基于 Linux 系统调用接口所实现的虚拟机。正是由于UML是一个将Linux作为用户空间进程运行的特性，可以使用UML来进行操作系统内核的调试。有关UML的介绍请查阅参考资料[10]、[12]。

4．1 UML的安装与调试

UML的安装需要一台运行Linux 2.2.15以上，或者2.3.22以上的I386机器。对于2.6.8及其以前版本的UML，采用两种形式发布：一种是以RPM包的形式发布，一种是以源代码的形式提供UML的安装。按照UML的说明，以RPM形式提供的安装包比较陈旧且会有许多问题。以二进制形式发布的UML包并不包含所需要的调试信息，这些代码在发布时已经做了程度不同的优化。所以，要想利用UML调试Linux系统内核，需要使用最新的UML patch代码和对应版本的Linux内核编译、安装UML。完成UML的补丁之后，会在arch目录下产生一个um目录，主要的UML代码都放在该目录下。

从2.6.9版本之后（包含2.6.9版本的Linux），User-Mode Linux已经随Linux内核源代码树一起发布，它存放于arch/um目录下。

编译好UML的内核之后，直接使用gdb运行已经编译好的内核即可进行调试。

4．2使用UML调试系统内核的特点和不足

目前，用户模式 Linux 虚拟机也存在一定的局限性。由于UML虚拟机是基于Linux系统调用接口的方式实现的虚拟机，所以用户模式内核不能访问主机系统上的硬件设备。因此，UML并不适合于调试那些处理实际硬件的驱动程序。不过，如果所编写的内核程序不是硬件驱动，例如Linux文件系统、协议栈等情况，使用UML作为调试工具还是一个不错的选择。

回页首

5. 内核调试配置选项

为了方便调试和测试代码，内核提供了许多与内核调试相关的配置选项。这些选项大部分都在内核配置编辑器的内核开发(kernel hacking)菜单项中。在内核配置目录树菜单的其他地方也还有一些可配置的调试选项，下面将对他们作一定的介绍。

Page alloc debugging ：CONFIG_DEBUG_PAGEALLOC:

不使用该选项时，释放的内存页将从内核地址空间中移出。使用该选项后，内核推迟移出内存页的过程，因此能够发现内存泄漏的错误。

Debug memory allocations ：CONFIG_DEBUG_SLAB:

该打开该选项时，在内核执行内存分配之前将执行多种类型检查，通过这些类型检查可以发现诸如内核过量分配或者未初始化等错误。内核将会在每次分配内存前后时设置一些警戒值，如果这些值发生了变化那么内核就会知道内存已经被操作过并给出明确的提示，从而使各种隐晦的错误变得容易被跟踪。

Spinlock debugging ：CONFIG_DEBUG_SPINLOCK:

打开此选项时，内核将能够发现spinlock未初始化及各种其他的错误,能用于排除一些死锁引起的错误。

Sleep-inside-spinlock checking：CONFIG_DEBUG_SPINLOCK_SLEEP:

打开该选项时，当spinlock的持有者要睡眠时会执行相应的检查。实际上即使调用者目前没有睡眠，而只是存在睡眠的可能性时也会给出提示。

Compile the kernel with debug info ：CONFIG_DEBUG_INFO:

打开该选项时，编译出的内核将会包含全部的调试信息，使用gdb时需要这些调试信息。

Stack utilization instrumentation ：CONFIG_DEBUG_STACK_USAGE:

该选项用于跟踪内核栈的溢出错误，一个内核栈溢出错误的明显的现象是产生oops错误却没有列出系统的调用栈信息。该选项将使内核进行栈溢出检查，并使内核进行栈使用的统计。

Driver Core verbose debug messages：CONFIG_DEBUG_DRIVER:

该选项位于"Device drivers-> Generic Driver Options"下，打开该选项使得内核驱动核心产生大量的调试信息，并将他们记录到系统日志中。

Verbose SCSI error reporting (kernel size +=12K) ：CONFIG_SCSI_CONSTANTS:

该选项位于"Device drivers/SCSI device support"下。当SCSI设备出错时内核将给出详细的出错信息。

Event debugging：CONFIG_INPUT_EVBUG:

打开该选项时，会将输入子系统的错误及所有事件都输出到系统日志中。该选项在产生了详细的输入报告的同时，也会导致一定的安全问题。

以上内核编译选项需要读者根据自己所进行的内核编程的实际情况，灵活选取。在使用以上介绍的三种源代码级的内核调试工具时，一般需要选取CONFIG_DEBUG_INFO选项，以使编译的内核包含调试信息。

回页首

6. 总结

上面介绍了一些调试Linux内核的方法，特别是详细介绍了三种源代码级的内核调试工具，以及搭建这些内核调试环境的方法，读者可以根据自己的情况从中作出选择。

调试工具（例如gdb）的运行都需要操作系统的支持，而此时内核由于一些错误的代码而不能正确执行对系统的管理功能，所以对内核的调试必须采取一些特殊的方法进行。以上介绍的三种源代码级的调试方法，可以归纳为以下两种策略：

I、为内核增加调试Stub，利用调试Stub进行远程调试，这种调试策略需要target及development机器才能完成调试任务。

II、将虚拟机技术与调试工具相结合，使Linux内核在虚拟机中运行从而利用调试器对内核进行调试。这种策略需要制作适合在虚拟机中运行的系统内核。

由不同的调试策略决定了进行调试时不同的工作原理，同时也形成了各种调试方法不同的软硬件需求和各自的特点。

另外，需要说明的是内核调试能力的掌握很大程度上取决于经验和对整个操作系统的深入理解。对系统内核的全面深入的理解，将能在很大程度上加快对Linux系统内核的开发和调试。

对系统内核的调试技术和方法绝不止上面介绍所涉及的内容，这里只是介绍了一些经常看到和听到方法。在Linux内核向前发展的同时，内核的调试技术也在不断的进步。希望以上介绍的一些方法能对读者开发和学习Linux有所帮助。

回页首

参考资料

[1] http://oss.sgi.com/projects/kdb/

[2] http://www.ibm.com/developerworks/cn/linux/sdk/l-debug/index.html

[3] http://www.ibm.com/developerworks/cn/linux/l-kdbug/

[4] http://www.ibm.com/developerworks/cn/linux/l-kprobes.html

[5] http://kgdb.linsyssoft.com/downloads.htm

[6] ftp://166.111.68.183

[8] http://www.uclinux.org/pub/uClinux/dist/

[9] http://opensrc.sec.samsung.com/download/linux-2.6.9-hsc0.patch.gz

[10] http:// www.kernel.org

[11] http://user-mode-linux.sourceforge.net/

[12] http://www.ibm.com/developerworks/cn/linux/l-skyeye/part1/

[13] http://www.ibm.com/developerworks/cn/views/linux/tutorials.jsp?cv_doc_id=84978

回页首

参考文献

[1]Robert Love Linux kernel development机械工业出版社

[2]陈渝 源代码开发的嵌入式系统软件分析与实践 北京航空航天大学出版社

[3]Alessandro Rubini Linux device driver 2se Edition O'Reilly

[4]Jonathan Corbet Linux device driver 3rd Edition O'Reilly

[5]李善平 Linux内核源代码分析大全 机械工业出版社

作者简介

$ cat -n exp1.sh1  ERRTRAP()2  {3    echo "[LINE:$1] Error: Command or function exited with status $?"4  }5  foo()6  {7    return 1;8  }9  trap 'ERRTRAP $LINENO' ERR10  abc11  foo

$ sh exp1.sh
exp1.sh: line 10: abc: command not found
[LINE:10] Error: Command or function exited with status 127
[LINE:11] Error: Command or function exited with status 1

$ cat –n exp2.sh1  #!/bin/bash2  trap 'echo “before execute line:$LINENO, a=$a,b=$b,c=$c”' DEBUG3  a=14  if [ "$a" -eq 1 ]5  then6     b=27  else8     b=19  fi10  c=311  echo "end"

$ sh exp2.sh
before execute line:3, a=,b=,c=
before execute line:4, a=1,b=,c=
before execute line:6, a=1,b=,c=
before execute line:10, a=1,b=2,c=
before execute line:11, a=1,b=2,c=3
end

ipaddr=`/sbin/ifconfig | grep 'inet addr:' | grep -v '127.0.0.1'
| cut -d : -f3 | awk '{print $1}'` 
#注意=号后面的整句是用反引号(数字1键的左边那个键)括起来的。
echo $ipaddr

ipaddr=`/sbin/ifconfig | grep 'inet addr:' | grep -v '127.0.0.1'
| tee temp.txt | cut -d : -f3 | awk '{print $1}'`
echo $ipaddr

$ cat temp.txt
inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

if [ “$DEBUG” = “true” ]; then
echo “debugging”  #此处可以输出调试信息
fi

$ cat –n exp3.sh1  DEBUG()2  {3  if [ "$DEBUG" = "true" ]; then4      $@　　5  fi6  }7  a=18  DEBUG echo "a=$a"9  if [ "$a" -eq 1 ]10  then11       b=212  else13       b=114  fi15  DEBUG echo "b=$b"16  c=317  DEBUG echo "c=$c"

$ sh –x exp2.sh
+ trap 'echo "before execute line:$LINENO, a=$a,b=$b,c=$c"' DEBUG
++ echo 'before execute line:3, a=,b=,c='
before execute line:3, a=,b=,c=
+ a=1
++ echo 'before execute line:4, a=1,b=,c='
before execute line:4, a=1,b=,c=
+ '[' 1 -eq 1 ']'
++ echo 'before execute line:6, a=1,b=,c='
before execute line:6, a=1,b=,c=
+ b=2
++ echo 'before execute line:10, a=1,b=2,c='
before execute line:10, a=1,b=2,c=
+ c=3
++ echo 'before execute line:11, a=1,b=2,c=3'
before execute line:11, a=1,b=2,c=3
+ echo end
end

set -x　　　 #启动"-x"选项 
要跟踪的程序段 
set +x　　　　 #关闭"-x"选项

DEBUG set -x　　　 #启动"-x"选项 
要跟踪的程序段 
DEBUG set +x　　　 #关闭"-x"选项

$ cat –n exp4.sh1  #!/bin/bash2  isRoot()3  {4          if [ "$UID" -ne 0 ]5                  return 16          else7                  return 08          fi9  }10  isRoot11  if ["$?" -ne 0 ]12  then13          echo "Must be root to run this script"14          exit 115  else16          echo "welcome root user"17          #do something18  fi

$ sh –n exp4.sh
exp4.sh: line 6: syntax error near unexpected token `else'
exp4.sh: line 6: `      else'

$ sh exp4.sh
exp2.sh: line 11: [1: command not found
welcome root user

$ export PS4='+{$LINENO:${FUNCNAME[0]}} '
$ sh –x exp4.sh
+{10:} isRoot
+{4:isRoot} '[' 503 -ne 0 ']'
+{5:isRoot} return 1
+{11:} '[1' -ne 0 ']'
exp4.sh: line 11: [1: command not found
+{16:} echo 'welcome root user'
welcome root user

+{4:isRoot} '[' 503 -ne 0 ']'
+{11:} '[1' -ne 0 ']'

使用 GDB 调试多进程程序

田 强 (tianq@cn.ibm.com), 软件工程师, IBM中国软件开发中心

简介： GDB 是 linux 系统上常用的调试工具，本文介绍了使用 GDB 调试多进程程序的几种方法，并对各种方法进行比较。

GDB 是 linux 系统上常用的 c/c++ 调试工具，功能十分强大。对于较为复杂的系统，比如多进程系统，如何使用 GDB 调试呢？考虑下面这个三进程系统：

进程

Proc2 是 Proc1 的子进程，Proc3 又是 Proc2 的子进程。如何使用 GDB 调试 proc2 或者 proc3 呢？

实际上，GDB 没有对多进程程序调试提供直接支持。例如，使用GDB调试某个进程，如果该进程fork了子进程，GDB会继续调试该进程，子进程会不受干扰地运行下去。如果你事先在子进程代码里设定了断点，子进程会收到SIGTRAP信号并终止。那么该如何调试子进程呢？其实我们可以利用GDB的特点或者其他一些辅助手段来达到目的。此外，GDB 也在较新内核上加入一些多进程调试支持。

接下来我们详细介绍几种方法，分别是 follow-fork-mode 方法，attach 子进程方法和 GDB wrapper 方法。

follow-fork-mode

在2.5.60版Linux内核及以后，GDB对使用fork/vfork创建子进程的程序提供了follow-fork-mode选项来支持多进程调试。

follow-fork-mode的用法为：

set follow-fork-mode [parent|child]

• parent: fork之后继续调试父进程，子进程不受影响。
• child: fork之后调试子进程，父进程不受影响。

因此如果需要调试子进程，在启动gdb后：

(gdb) set follow-fork-mode child

并在子进程代码设置断点。

此外还有detach-on-fork参数，指示GDB在fork之后是否断开（detach）某个进程的调试，或者都交由GDB控制：

set detach-on-fork [on|off]

• on: 断开调试follow-fork-mode指定的进程。
• off: gdb将控制父进程和子进程。follow-fork-mode指定的进程将被调试，另一个进程置于暂停（suspended）状态。

注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。

follow-fork-mode/detach-on-fork的使用还是比较简单的，但由于其系统内核/gdb版本限制，我们只能在符合要求的系统上才能使用。而且，由于follow-fork-mode的调试必然是从父进程开始的，对于fork多次，以至于出现孙进程或曾孙进程的系统，例如上图3进程系统，调试起来并不方便。

Attach子进程

众所周知，GDB有附着（attach）到正在运行的进程的功能，即attach <pid>命令。因此我们可以利用该命令attach到子进程然后进行调试。

例如我们要调试某个进程RIM_Oracle_Agent.9i，首先得到该进程的pid

[root@tivf09 tianq]# ps -ef|grep RIM_Oracle_Agent.9i nobody 6722 6721 0 05:57 ? 00:00:00 RIM_Oracle_Agent.9i root 7541 27816 0 06:10 pts/3 00:00:00 grep -i rim_oracle_agent.9i

通过pstree可以看到，这是一个三进程系统，oserv是RIM_Oracle_prog的父进程，RIM_Oracle_prog又是RIM_Oracle_Agent.9i的父进程。

[root@tivf09 root]# pstree -H 6722

通过 pstree 察看进程

启动GDB，attach到该进程

用 GDB 连接进程

现在就可以调试了。一个新的问题是，子进程一直在运行，attach上去后都不知道运行到哪里了。有没有办法解决呢？

一个办法是，在要调试的子进程初始代码中，比如main函数开始处，加入一段特殊代码，使子进程在某个条件成立时便循环睡眠等待，attach到进程后在该代码段后设上断点，再把成立的条件取消，使代码可以继续执行下去。

至于这段代码所采用的条件，看你的偏好了。比如我们可以检查一个指定的环境变量的值，或者检查一个特定的文件存不存在。以文件为例，其形式可以如下：

void debug_wait(char *tag_file) {while(1){if (tag_file存在)睡眠一段时间;elsebreak;} }

当attach到进程后，在该段代码之后设上断点，再把该文件删除就OK了。当然你也可以采用其他的条件或形式，只要这个条件可以设置/检测即可。

Attach进程方法还是很方便的，它能够应付各种各样复杂的进程系统，比如孙子/曾孙进程，比如守护进程（daemon process），唯一需要的就是加入一小段代码。

GDB wrapper

很多时候，父进程 fork 出子进程，子进程会紧接着调用 exec族函数来执行新的代码。对于这种情况，我们也可以使用gdb wrapper 方法。它的优点是不用添加额外代码。

其基本原理是以gdb调用待执行代码作为一个新的整体来被exec函数执行，使得待执行代码始终处于gdb的控制中，这样我们自然能够调试该子进程代码。

还是上面那个例子，RIM_Oracle_prog fork出子进程后将紧接着执行RIM_Oracle_Agent.9i的二进制代码文件。我们将该文件重命名为RIM_Oracle_Agent.9i.binary，并新建一个名为RIM_Oracle_Agent.9i的shell脚本文件，其内容如下：

[root@tivf09 bin]# mv RIM_Oracle_Agent.9i RIM_Oracle_Agent.9i.binary [root@tivf09 bin]# cat RIM_Oracle_Agent.9i #!/bin/sh gdb RIM_Oracle_Agent.binary

当fork的子进程执行名为RIM_Oracle_Agent.9i的文件时，gdb会被首先启动，使得要调试的代码处于gdb控制之下。

新的问题来了。子进程是在gdb的控制下了，但还是不能调试：如何与gdb交互呢？我们必须以某种方式启动gdb，以便能在某个窗口/终端与gdb交互。具体来说，可以使用xterm生成这个窗口。

xterm是X window系统下的模拟终端程序。比如我们在Linux桌面环境GNOME中敲入xterm命令：

xterm

就会跳出一个终端窗口：

终端

如果你是在一台远程linux服务器上调试，那么可以使用VNC(Virtual Network Computing) viewer从本地机器连接到服务器上使用xterm。在此之前，需要在你的本地机器上安装VNC viewer，在服务器上安装并启动VNC server。大多数linux发行版都预装了vnc-server软件包，所以我们可以直接运行vncserver命令。注意，第一次运行vncserver时会提示输入密码，用作VNC viewer从客户端连接时的密码。可以在VNC server机器上使用vncpasswd命令修改密码。

[root@tivf09 root]# vncserver New 'tivf09:1 (root)' desktop is tivf09:1Starting applications specified in /root/.vnc/xstartup Log file is /root/.vnc/tivf09:1.log[root@tivf09 root]# [root@tivf09 root]# ps -ef|grep -i vnc root 19609 1 0 Jun05 ? 00:08:46 Xvnc :1 -desktop tivf09:1 (root) -httpd /usr/share/vnc/classes -auth /root/.Xauthority -geometry 1024x768 -depth 16 -rfbwait 30000 -rfbauth /root/.vnc/passwd -rfbport 5901 -pn root 19627 1 0 Jun05 ? 00:00:00 vncconfig -iconic root 12714 10599 0 01:23 pts/0 00:00:00 grep -i vnc [root@tivf09 root]#

Vncserver是一个Perl脚本，用来启动Xvnc（X VNC server）。X client应用，比如xterm，VNC viewer都是和它通信的。如上所示，我们可以使用的DISPLAY值为tivf09:1。现在就可以从本地机器使用VNC viewer连接过去：

VNC viewer：输入服务器

输入密码：

VNC viewer：输入密码

登录成功，界面和服务器本地桌面上一样：

VNC viewer

下面我们来修改RIM_Oracle_Agent.9i脚本，使它看起来像下面这样：

#!/bin/sh export DISPLAY=tivf09:1.0; xterm -e gdb RIM_Oracle_Agent.binary

如果你的程序在exec的时候还传入了参数，可以改成：

#!/bin/sh export DISPLAY=tivf09:1.0; xterm -e gdb --args RIM_Oracle_Agent.binary $@

最后加上执行权限

[root@tivf09 bin]# chmod 755 RIM_Oracle_Agent.9i

现在就可以调试了。运行启动子进程的程序：

[root@tivf09 root]# wrimtest -l 9i_linux Resource Type : RIM Resource Label : 9i_linux Host Name : tivf09 User Name : mdstatus Vendor : Oracle Database : rim Database Home : /data/oracle9i/920 Server ID : rim Instance Home : Instance Name : Opening Regular Session...

程序停住了。从VNC viewer中可以看到，一个新的gdb xterm窗口在服务器端打开了

gdb xterm 窗口

[root@tivf09 root]# ps -ef|grep gdb nobody 24312 24311 0 04:30 ? 00:00:00 xterm -e gdb RIM_Oracle_Agent.binary nobody 24314 24312 0 04:30 pts/2 00:00:00 gdb RIM_Oracle_Agent.binary root 24326 10599 0 04:30 pts/0 00:00:00 grep gdb

运行的正是要调试的程序。设置好断点，开始调试吧！

注意，下面的错误一般是权限的问题，使用 xhost 命令来修改权限：

xterm 错误

[root@tivf09 bin]# export DISPLAY=tivf09:1.0 [root@tivf09 bin]# xhost + access control disabled, clients can connect from any host

xhost + 禁止了访问控制，从任何机器都可以连接过来。考虑到安全问题，你也可以使用xhost + <你的机器名>。

小结

上述三种方法各有特点和优劣，因此适应于不同的场合和环境：

• follow-fork-mode方法：方便易用，对系统内核和GDB版本有限制，适合于较为简单的多进程系统
• attach子进程方法：灵活强大，但需要添加额外代码，适合于各种复杂情况，特别是守护进程
• GDB wrapper方法：专用于fork+exec模式，不用添加额外代码，但需要X环境支持（xterm/VNC）。

参考资料

• GDB 官方参考资料：http://sourceware.org/gdb/documentation/
  
  
• 更多 VNC 信息：http://www.realvnc.com/
  
  

关于作者