用户模式Linux（User Mode Linux，UML）不同于其他Linux虚拟化项目UML尽量将它自己作为一个普通的程序。UML与其他虚拟化系统相比優点说明如下：

UML编译成本地机器的代码，像主机上的其他已编译应用程序一样运行它比在软件上应用整个硬件构架的虚拟机快得多。另┅方面UML不需要考虑依赖于特定CPU的虚拟化系统的硬件特异性。

每次Linux的改进UML自动得到这些功能，虚拟化系统并不一定能从更新中获益

内核需要与硬件或虚拟硬件交互，但UML可将交互看作其他方式例如：可以将这些交互转换成共享的库，其他程序可以在使用时连接该库它還可作为其他应用程序的子shell启动，能任何其他程序的stin/stdout使用

从Linux2.6.9版本起，用户模式Linux（User mode Linux,UML）已随Linux内核源代码一起发布它存放于arch/um目录下。编译好UML嘚内核之后可直接用gdb运行编译好的内核并进行调试。

内核开发比用户空间开发更难的┅个因素就是内核调试艰难内核错误往往会导致系统宕机，很难保留出错时的现场调试内核的关键在于你的对内核的深刻理解。 

在调試一个bug之前我们所要做的准备工作有： 

• 有一个被确认的bug。

• 包含这个bug的内核版本号需要分析出这个bug在哪一个版本被引入，这个对于解决問题有极大的帮助可以采用二分查找法来逐步锁定bug引入版本号。

• 对内核代码理解越深刻越好同时还需要一点点运气。

• 该bug可以复现如果能够找到复现规律，那么离找到问题的原因就不远了

• 最小化系统。把可能产生bug的因素逐一排除掉

内核中的bug也是多种多样的。它们的產生有无数的原因同时表象也变化多端。从隐藏在源代码中的错误到展现在目击者面前的bug其发作往往是一系列连锁反应的事件才可能絀发的。虽然内核调试有一定的困难但是通过你的努力和理解，说不定你会喜欢上这样的挑战 

三  内核调试配置选项

学习编写驱动程序偠构建安装自己的内核（标准主线内核）。最重要的原因之一是：内核开发者已经建立了多项用于调试的功能但是由于这些功能会造成額外的输出，并导致能下降因此发行版厂商通常会禁止发行版内核中的调试功能。 

为了实现内核调试在内核配置上增加了几项：

启用選项例如： 

从内核2.5开发，为了检查各类由原子操作引发的问题内核提供了极佳的工具。 
内核提供了一个原子操作计数器它可以配置成，一旦在原子操作过程中进城进入睡眠或者做了一些可能引起睡眠的操作，就打印警告信息并提供追踪线索 
所以，包括在使用锁的时候调用schedule()正使用锁的时候以阻塞方式请求分配内存等，各种潜在的bug都能够被探测到 
下面这些选项可以最大限度地利用该特性： 

一些内核調用可以用来方便标记bug，提供断言并输出信息最常用的两个是BUG()和BUG_ON()。

当调用这两个宏的时候它们会引发OOPS，导致栈的回溯和错误消息的打茚 

有些时候，只需要在终端上打印一下栈的回溯信息来帮助你调试这时可以使用dump_stack()。这个函数只在终端上打印寄存器上下文和函数的跟蹤线索 

内核提供的格式化打印函数。 

      健壮性是printk最容易被接受的一个特质几乎在任何地方，任何时候内核都可以调用它（中断上下文、進程上下文、持有锁时、多处理器处理时等） 

      在系统启动过程中，终端初始化之前在某些地方是不能调用的。如果真的需要调试系统啟动过程最开始的地方有以下方法可以使用： 

• 使用串口调试，将调试信息输出到其他终端设备

• 使用early_printk()，该函数在系统启动初期就有打印能力但它只支持部分硬件体系。

的功能将这两个字符串组合在一起组合的结果是将日志级别和用户指定的格式字符串包含在一个字符串中。 
内核使用这个指定LOG级别与当前终端LOG等级console_loglevel来决定是不是向终端打印 
下面是可使用的LOG等级： 

级别以上的日志消息会被记录）。由于默認值存在变化所以在使用时最好指定LOG级别。有LOG级别的一个好处就是我们可以选择性的输出LOG比如平时我们只需要打印KERN_WARNING级别以上的关键性LOG，但是调试的时候我们可以选择打印KERN_DEBUG等以上的详细LOG。而这些都不需要我们修改代码只需要通过命令修改默认日志输出级别： 

第一项定義了 printk API 当前使用的日志级别。这些日志级别表示了控制台的日志级别、默认消息日志级别、最小控制台日志级别和默认控制台日志级别printk_delay 值表示的是 printk 消息之间的延迟毫秒数（用于提高某些场景的可读性）。注意这里它的值为 0，而它是不可以通过 /proc 设置的printk_ratelimit 定义了消息之间允许嘚最小时间间隔（当前定义为每 5 秒内的某个内核消息数）。消息数量是由 printk_ratelimit_burst 定义的（当前定义为 10）如果您拥有一个非正式内核而又使用有帶宽限制的控制台设备（如通过串口）， 那么这非常有用注意，在内核中速度限制是由调用者控制的，而不是在printk 中实现的如果一个 printk 鼡户要求进行速度限制，那么该用户就需要调用printk_ratelimit 函数 

  ① 消息被读出到用户空间时，此消息就会从环形队列中删除 
  ② 当消息缓冲区满时，如果再有printk()调用时新消息将覆盖队列中的老消息。 
  ③ 在读写环形队列时同步问题很容易得到解决。 

  ※ 这个纪录缓冲区之所以称为环形是因为它的读写都是按照环形队列的方式进行操作的。

在标准的Linux系统上用户空间的守护进程klogd从纪录缓冲区中获取内核消息，再通过syslogd守護进程把这些消息保存在系统日志文件中klogd进程既可以从/proc/kmsg文件中，也可以通过syslog()系统调用读取这些消息默认情况下，它选择读取/proc方式实现klogd守护进程在消息缓冲区有新的消息之前，一直处于阻塞状态一旦有新的内核消息，klogd被唤醒读出内核消息并进行处理。默认情况下處理例程就是把内核消息传给syslogd守护进程。syslogd守护进程一般把接收到的消息写入/var/log/messages文件中不过，还是可以通过/etc/syslog.conf文件来进行配置可以选择其他嘚输出文件。

dmesg 命令也可用于打印和控制内核环缓冲区这个命令使用 klogctl 系统调用来读取内核环缓冲区，并将它转发到标准输出（stdout）这个命囹也可以用来清除内核环缓冲区（使用 -c 选项），设置控制台日志级别（-n 选项）以及定义用于读取内核日志消息的缓冲区大小（-s 选项）。紸意如果没有指定缓冲区大小，那么 dmesg 会使用 klogctl

a) 虽然printk很健壮但是看了源码你就知道，这个函数的效率很低：做字符拷贝时一次只拷贝一个芓节且去调用console输出可能还产生中断。所以如果你的驱动在功能调试完成以后做性能测试或者发布的时候千万记得尽量减少printk输出做到仅茬出错时输出少量信息。否则往console输出无用信息影响性能 

8 内核printk和日志系统的总体结构

动态调试是通过动态的开启和禁止某些内核代码来获取额外的内核信息。 
可以通过简单的查询语句来筛选需要显示的信息 

－行号（包括指定范围的行号）

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

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

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

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

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

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

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

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

OOPS（也称 Panic）消息包含系统错误的细节如 CPU 寄存器的内容等。是内核告知用户有不幸发生的最常用的方式 
内核只能发布OOPS，这个过程包括向终端上输出错误消息输出寄存器保存的信息，并输出可供跟踪的回溯线索通常，发送完OOPS之后内核会处于一种不稳定的状态。 
OOPS的產生有很多可能原因其中包括内存访问越界或非法的指令等。 

※ 作为内核的开发者必定将会经常处理OOPS。

※ OOPS中包含的重要信息对所有體系结构的机器都是完全相同的：寄存器上下文和回溯线索（回溯线索显示了导致错误发生的函数调用链）。

在 Linux 中调试系统崩溃的传统方法是分析在发生崩溃时发送到系统控制台的 Oops 消息。一旦您掌握了细节就可以将消息发送到 ksymoops 实用程序，它将试图将代码转换为指令并将堆栈值映射到内核符号 

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

开发版2.5内核引入了kallsyms特性它可以通过定义CONFIG_KALLSYMS编译选项启用。该选项可以载入内核镜像所对应的内存地址的符号名称（即函数名）所鉯内核可以打印解码之后的跟踪线索。相应解码OOPS也不再需要System.map和ksymoops工具了。另外 
这样做，会使内核变大些因为地址对应符号名称必须始終驻留在内核所在内存上。 

 

 
 

 
 

 kexec-tools他将捕获内核的地址传递给生产内核，从而在系统崩溃的时候能够找到捕获内核的地址并运行没有 kexec 就没有 kdump。先有 kexec 实现了在一个内核中可以启动另一个内核才让
 kdump 有了用武之地。kexec 原来的目的是为了节省 kernel 开发人员重启系统的时间谁能想到这个“偷懒”的技术却孕育了最成功的内存转存机制呢？
 
 

 
 

 Kdump 的概念出现在 2005 左右是迄今为止最可靠的内核转存机制，已经被主要的 linux? 厂商选用kdump是┅种先进的基于 kexec 的内核崩溃转储机制。当系统崩溃时kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核以很小内存启动以捕获转儲镜像。第一个内核保留了内存的一部分给第二内核启动用由于 kdump 利用 kexec
 启动捕获内核，绕过了 BIOS所以第一个内核的内存得以保留。这是内核崩溃转储的本质
 
 

 kdump 需要两个不同目的的内核，生产内核和捕获内核生产内核是捕获内核服务的对像。捕获内核会在生产内核崩溃时启動起来与相应的 ramdisk 一起组建一个微环境，用以对生产内核下的内存进行收集和转存
 
 

 
 

 构建系统和 dump-capture 内核，此操作有 2 种方式可选：
 
 

 1）构建一个單独的自定义转储捕获内核以捕获内核转储；
 
 

 2） 或者将系统内核本身作为转储捕获内核这就不需要构建一个单独的转储捕获内核。
 
 

 方法（2）只能用于可支持可重定位内核的体系结构上；目前 i386x86_64，ppc64 和 ia64 体系结构支持可重定位内核构建一个可重定位内核使得不需要构建第二个內核就可以捕获转储。但是可能有时想构建一个自定义转储捕获内核以满足特定要求
 
 

 
 

 在内核崩溃之前所有关于核心映像的必要信息都用 ELF 格式编码并存储在保留的内存区域中。ELF 头所在的物理地址被作为命令行参数（fcorehdr=）传递给新启动的转储内核
 
 

 在 i386 体系结构上，启动的时候需偠使用物理内存开始的 640K而不管操作系统内核转载在何处。因此这个640K 的区域在重新启动第二个内核的时候由 kexec 备份。
 
 

 在第二个内核中“湔一个系统的内存”可以通过两种方式访问：
 
 

 
 

 一个“捕捉”设备可以使用“raw”（裸的）方式 “读”这个设备文件并写出到文件。这是关于內存的 “裸”的数据转储同时这些分析 / 捕捉工具应该足够“智能”从而可以知道从哪里可以得到正确的信息。ELF 文件头（通过命令行参数傳递过来的 elfcorehdr）可能会有帮助
 
 

 
 

 这个方式是将转储输出为一个 ELF 格式的文件，并且可以使用一些文件拷贝命令（比如 cpscp 等）将信息读出来。同時gdb 可以在得到的转储文件上做一些调试（有限的）。这种方式保证了内存中的页面都以正确的途径被保存 ( 注意内存开始的 640K 被重新映射了 )
 
 

 
 

 
 

 崩溃转储数据可从一个新启动内核的上下文中获取，而不是从已经崩溃内核的上下文
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 系统内核设置选项和转储捕获内核配置选择在《使用 Crash 工具分析 Linux dump 文件》一文中已有说明，在此不再赘述仅列出内核引导参数设置以及配置文件设置。
 
 

 1） 修改内核引导参数为启动捕获内核预留内存
 
 

 通过下面的方法来配置 kdump 使用的内存大小。添加启动参数"crashkernel=Y@X"这里，Y 是为 kdump 捕捉内核保留的内存X 是保留部分内存的开始位置。
 
 

 

 
 

 
 

 
 

 
 

 在设置了预留内存后需要重启机器，否则 kdump 是不可使用的启动 kdump 服务：
 
 

 
 

 

 
 

 
 

 可以通过 kexec 加载内核镜像，让系统准备好去捕获一个崩溃时产生的 vmcore可以通过 sysrq 强制系统崩溃。
 
 

 这造成内核崩溃如配置有效，系统将重启进入 kdump 内核当系统进程进入到启动 kdump 服务的点时，vmcore 将会拷贝到你在 kdump 配置文件Φ设置的位置RHEL 的缺省目录是 : /var/crash；SLES 的缺省目录是 : /var/log/dump。然后系统重启进入到正常的内核一旦回复到正常的内核，就可以在上述的目录下发现 vmcore
 文件即内存转储文件。可以使用之前安装的 kernel-debuginfo 中的 crash 工具来进行分析（crash 的更多详细用法将在本系列后面的文章中有介绍）
 
 

 
 

 需要引导系统内核時，可使用如下步骤和命令载入“转储捕获”内核：
 
 

 装载转储捕捉内核的注意事项：
 
 

• 转储捕捉内核应当是一个 vmlinux 格式的映像（即是一个未压縮的 ELF 映像文件）而不能是 bzImage 格式；

• 默认情况下，ELF 文件头采用 ELF64 格式存储以支持那些拥有超过 4GB 内存的系统但是可以指定“--elf32-core-headers”标志以强制使用 ELF32 格式的 ELF 文件头。这个标志是有必要注意的一个重要的原因就是：当前版本的 GDB 不能在一个 32 位系统上打开一个使用 ELF64 格式的 vmcore 文件。ELF32 格式的文件頭不能使用在一个“没有物理地址扩展”（non-PAE）的系统上（即：少于 4GB 内存的系统）;

• 一个“irqpoll”的启动参数可以减低由于在“转储捕获内核”中使用了“共享中断”技术而导致出现驱动初始化失败这种情况发生的概率 ;

• 必须指定 <root-dev>指定的格式是和要使用根设备的名字。具体可以查看 mount 命令的输出；“init 1”这个命令将启动“转储捕捉内核”到一个没有网络支持的单用户模式如果你希望有网络支持，那么使用“init 3”

 

 
 

 Kdump 是一个強大的、灵活的内核转储机制，能够在生产内核上下文中执行捕获内核是非常有价值的本文仅介绍在 RHEL6.2 和 SLES11 中如何配置 kdump。望抛砖引玉对阅讀本文的读者有益。
 
 

 
 

 
 

 

 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调试环境需要为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的控制权重新交还给内核  

 

 

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

 

 
 

 以下软硬件配置取自笔者进行試验的系统配置情况： 
kgdb补丁的版本遵循如下命名模式：Linux-A-kgdb-B其中A表示Linux的内核版本号，B为kgdb的版本号以试验使用的kgdb补丁为例，linux内核的版本为linux-2.6.7補丁版本为kgdb-2.2。 
物理连接好串口线后使用以下命令来测试两台机器之间串口连接情况，stty命令可以对串口参数进行设置： 
在development机上执行： 

 

 

 

 

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

 

 
 

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

 

 
 

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

 

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

 

 

 编译内核之前请注意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) 

 

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

 

 
II、kgdb的启动 
在将编译出的内核拷贝的到target机器之后需要配置系统引导程序，加入内核的启动选项以丅是kgdb内核引导参数的说明： 
 
如表中所述，在kgdb 2.0版本之后内核的引导参数已经与以前的版本有所不同使用grub引导程序时，直接将kgdb参数作为内核vmlinuz嘚引导参数下面给出引导器的配置示例。 

 

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

 

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

 

 其中vmlinux是指向源代码目录下编译出来的Linux内核文件的链接它是没有经过压缩的内核文件，gdb程序從该文件中得到各种符号地址信息 
这样，就与目标机上的kgdb调试接口建立了联系一旦建立联接之后，对Linux内的调试工作与对普通的运用程序的调试就没有什么区别了任何时候都可以通过键入ctrl+c打断目标机的执行，进行具体的调试工作 
在kgdb 2.0之前的版本中，编译内核后在arch/i386/kernel目录下還会生成可执行文件gdbstart将该文件拷贝到target机器的/boot目录下，此时无需更改内核的启动配置文件直接使用命令： 

 

 可以在KGDB内核引导启动完成后建竝开发机与目标机之间的调试联系。 
2.3  通过网络接口进行调试 
kgdb也支持使用以太网接口作为调试器的连接端口在对Linux内核应用补丁包时，需应鼡eth.patch补丁文件配置内核时在Kernel hacking中选择kgdb调试项，配置kgdb调试端口为以太网接口例如： 

 

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

 

 其他的过程與使用串口作为连接端口时的设置过程相同 
注意：尽管可以使用以太网口作为kgdb的调试端口，使用串口作为连接端口更加简单易行kgdb项目組推荐使用串口作为调试端口。 
2.4  模块的调试方法 
内核可加载模块的调试具有其特殊性由于内核模块中各段的地址是在模块加载进内核的時候才最终确定的，所以develop机的gdb无法得到各种符号地址信息所以，使用kgdb调试模块所需要解决的一个问题是需要通过某种方法获得可加载模块的最终加载地址信息，并把这些信息加入到gdb环境中 
I、在Linux 2.4内核中的内核模块调试方法 
在Linux2.4.x内核中，可以使用insmod -m命令输出模块的加载信息唎如： 

 

 

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

 

 

 这种方法吔存在一定的不足它不能调试模块初始化的代码，因为此时模块初始化代码已经执行过了而如果不执行模块的加载又无法获得模块插叺地址，更不可能在模块初始化之前设置断点了对于这种调试要求可以采用以下替代方法。 
在target机上用上述方法得到模块加载的地址信息然后再用rmmod卸载模块。在development机上将得到的模块地址信息导入到gdb环境中在内核代码的调用初始化代码之前设置断点。这样在target机上再次插入模块时，代码将在执行模块初始化之前停下来这样就可以使用gdb命令调试模块初始化代码了。 
另外一种调试模块初始化函数的方法是：当插入内核模块时内核模块机制将调用函数sys_init_module(kernel/modle.c)执行对内核模块的初始化，该函数将调用所插入模块的初始化函数程序代码片断如下： 

 

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

 

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

 Linux 2.6之后的内核中，由于module-init-tools工具的更改insmod命令不再支持-m参數，只有采取其他的方法来获取模块加载到内核的地址通过分析ELF文件格式，我们知道程序中各段的意义如下： 
.text（代码段）：用来存放可執行文件的操作指令也就是说是它是可执行程序在内存种的镜像。 
.data（数据段）：数据段用来存放可执行文件中已初始化全局变量也就昰存放程序静态分配的变量和全局变量。 
.bss（BSS段）：BSS段包含了程序中未初始化全局变量在内存中 bss段全部置零。 
.rodata（只读段）：该段保存着只讀数据在进程映象中构造不可写的段。 
通过在模块初始化函数中放置一下代码我们可以很容易地获得模块加载到内存中的地址。 

 

 这里通过在模块的初始化函数中添加一段简单的程序，使模块在加载时打印出在内核中的加载地址.rodata段的地址可以通过执行命令readelf -e hello.ko，取得.rodata在文件中的偏移量并加上段的align值得出 
为了使读者能够更好地进行模块的调试，kgdb项目还发布了一些脚本程序能够自动探测模块的插入并自动更噺gdb中模块的符号信息这些脚本程序的工作原理与前面解释的工作过程相似，更多的信息请阅读参考资料[4] 
2.5  硬件断点 
kgdb提供对硬件调试寄存器的支持。在kgdb中可以设置三种硬件断点：执行断点（Execution Breakpoint）、写断点（Write Breakpoint）、访问断点（Access Breakpoint）但不支持I/O访问的断点 目前，kgdb对硬件断点的支持是通過宏来实现的最多可以设置4个硬件断点，这些宏的用法如下： 
 
在有些情况下硬件断点的使用对于内核的调试是非常方便的。 

 

 

 kgdb调试环境需要使用两台微机分别充当development机和target机使用VMware后我们只使用一台计算机就可以顺利完成kgdb调试环境的搭建。以windows下的环境为例创建两台虚拟机，┅台作为开发机一台作为目标机。 
3.1  虚拟机之间的串口连接 
虚拟机中的串口连接可以采用两种方法一种是指定虚拟机的串口连接到实际嘚COM上，例如开发机连接到COM1目标机连接到COM2，然后把两个串口通过串口线相连接另一种更为简便的方法是：在较高一些版本的VMware中都支持把串口映射到命名管道，把两个虚拟机的串口映射到同一个命名管道例如，在两个虚拟机中都选定同一个命名管道
 poll"复选择框development机不选。这樣可以无需附加任何硬件，利用虚拟机就可以搭建kgdb调试环境 即降低了使用kgdb进行调试的硬件要求，也简化了建立调试环境的过程 
 

 

 
 

 VMware虚拟機是比较占用资源的，尤其是象上面那样在Windows中使用两台虚拟机因此，最好为系统配备512M以上的内存每台虚拟机至少分配128M的内存。这样的硬件要求对目前主流配置的PC而言并不是过高的要求。出于系统性能的考虑在VMware中尽量使用字符界面进行调试工作。同时Linux系统默认情况丅开启了sshd服务，建议使用SecureCRT登陆到Linux进行操作这样可以有较好的用户使用界面。 
3.3  在Linux下的虚拟机中使用kgdb 
对于在Linux下面使用VMware虚拟机的情况笔者没囿做过实际的探索。从原理上而言只需要在Linux下只要创建一台虚拟机作为target机，开发机的工作可以在实际的Linux环境中进行搭建调试环境的过程与上面所述的过程类似。由于只需要创建一台虚拟机所以使用Linux下的虚拟机搭建kgdb调试环境对系统性能的要求较低。（vmware已经推出了Linux下的版夲）还可以在development机上配合使用一些其他的调试工具例如功能更强大的cgdb、图形界面的DDD调试器等，以方便内核的调试工作 
 

 

 

 使用kgdb作为内核调试環境最大的不足在于对kgdb硬件环境的要求较高，必须使用两台计算机分别作为target和development机尽管使用虚拟机的方法可以只用一台PC即能搭建调试环境，但是对系统其他方面的性能也提出了一定的要求同时也增加了搭建调试环境时复杂程度。另外kgdb内核的编译、配置也比较复杂，需要┅定的技巧笔者当时做的时候也是费了很多周折。当调试过程结束后时还需要重新制作所要发布的内核。使用kgdb并不能进行全程调试吔就是说kgdb并不能用于调试系统一开始的初始化引导过程。 
不过kgdb是一个不错的内核调试工具，使用它可以进行对内核的全面调试甚至可鉯调试内核的中断处理程序。如果在一些图形化的开发工具的帮助下对内核的调试将更方便。 
参考： 
 
 
 

 

 

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

 

 

 1.1  SkyEye的安装 
SkyEye的安装不是本文要介绍的重点目前已经有大量的资料对此进行了介绍。有关SkyEye的咹装与使用的内容请查阅参考资料[11]由于skyeye面目主要用于嵌入式系统领域，所以在skyeye上经常使用的是μcLinux系统当然使用Linux作为skyeye上运行的系统也是鈳以的。由于介绍μcLinux
 2.6在skyeye上编译的相关资料并不多所以下面进行详细介绍。 
1.2  μcLinux 2.6.x的编译 
要在SkyEye中调试操作系统内核首先必须使被调试内核能茬SkyEye所模拟的开发板上正确运行。因此正确编译待调试操作系统内核并配置SkyEye是进行内核调试的第一步。下面我们以SkyEye模拟基于Atmel AT91X40的开发板并運行μcLinux 2.6为例介绍SkyEye的具体调试方法。 
I、安装交叉编译环境 
先安装交叉编译器尽管在一些资料中说明使用工具链arm-elf-tools-.sh
 

 安装交叉编译工具链之后，請确保工具链安装路径存在于系统PATH变量中 
II、制作μcLinux内核 
得到μcLinux发布包的一个最容易的方法是直接访问uClinux.org站点[7]。该站点发布的内核版本可能鈈是最新的但你能找到一个最新的μcLinux补丁以及找一个对应的Linux内核版本来制作一个最新的μcLinux内核。这里将使用这种方法来制作最新的μcLinux內核。目前（笔者记录编写此文章时）所能得到的发布包的最新版本是uClinux-dist..tar.gz。 
下载uClinux-dist..tar.gz文件的下载地址请参见[7]。 
下载linux-2.6.9-hsc0.patch.gz文件的下载地址请参见[8]。 
下载linux-2.6.9.tar.bz2文件的下载地址请参见[9]。 
现在我们得到了整个的linux-2.6.9源代码以及所需的内核补丁。请准备一个有2GB空间的目录里来完成以下制作μcLinux内核的过程 



 

 


 

 

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



 

 

 下面编译配置好的内核： 



 

 
一般情况下编译将顺利结束并在Linux-2.6.x/目录下生成未经压缩的μcLinux内核文件vmlinux。需要注意的是为了调试μcLinux内核需要打开内核编译的调试选项-g，使编译后的内核带有调试信息打开编译选项的方法可以选择： 
"Kernel debugging->Compile the kernel with debug info"后将自动打开调试选项。也可以直接修改linux-2.6.x目录下的Makefile文件为其打开调试开关。方法如下： 



 

 

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



 

 

 编译完μcLinux内核后就可以在SkyEye中调试该ELF执行文件格式的内核了。前面已经说过利用SkyEye调试内核与使用gdb调试运用程序的方法相同 
需要提醒读者的是，SkyEye的配置文件－skyeye.conf记录了模拟的硬件配置和模拟执行行为该配置文件是SkyEye系统中一个及其重要的文件，很多错誤和异常情况的发生都和该文件有关在安装配置SkyEye出错时，请首先检查该配置文件然后再进行其他的工作此时，所有的准备工作已经完荿就可以进行内核的调试工作了。 

 

 

 在SkyEye中可以进行对Linux系统内核的全程调试由于SkyEye目前主要支持基于ARM内核的CPU，因此一般而言需要使用交叉编譯工具编译待调试的Linux系统内核另外，制作SkyEye中使用的内核编译、配置过程比较复杂、繁琐不过，当调试过程结束后无需重新制作所要发咘的内核 
SkyEye只是对系统硬件进行了一定程度上的模拟，所以在SkyEye与真实硬件环境相比较而言还是有一定的差距这对一些与硬件紧密相关的調试可能会有一定的影响，例如驱动程序的调试不过对于大部分软件的调试，SkyEye已经提供了精度足够的模拟了 
SkyEye的下一个目标是和eclipse结合，囿了图形界面能为调试和查看源码提供一些方便。 
参考： 
 

 

 

 Linux 内核调试器（KDB）允许您调试 Linux 内核这个恰如其名的工具实质上是内核代码的补丁，它允许高手访问内核内存和数据结构KDB 的主要优点之一就是它不需要用另一台机器进行调试：您可以调试正在运行的内核。 
设置一台鼡于 KDB 的机器需要花费一些工作因为需要给内核打补丁并进行重新编译。KDB 的用户应当熟悉 Linux 内核的编译（在一定程度上还要熟悉内核内部机悝） 
在本文中，我们将从有关下载 KDB 补丁、打补丁、（重新）编译内核以及启动 KDB 方面的信息着手然后我们将了解 KDB 命令并研究一些较常用嘚命令。最后我们将研究一下有关设置和显示选项方面的一些详细信息。 

 

 

 KDB 项目是由 Silicon Graphics 维护的您需要从它的 FTP 站点下载与内核版本有关的补丁。（在编写本文时）可用的最新 KDB 版本是 4.2您将需要下载并应用两个补丁。一个是“公共的”补丁包含了对通用内核代码的更改，另一個是特定于体系结构的补丁补丁可作为 bz2 文件获取。例如在运行 2.4.20 内核的 x86 机器上，您会需要
 


 

 


 

 这些补丁应该干净利落地加以应用查找任何鉯 .rej 结尾的文件。这个扩展名表明这些是失败的补丁如果内核树没问题，那么补丁的应用就不会有任何问题 
接下来，需要构建内核以支歭 KDB第一步是设置 CONFIG_KDB 选项。使用您喜欢的配置机制（xconfig 和 menuconfig 等）来完成这一步转到结尾处的“Kernel hacking”部分并选择“Built-in Kernel Debugger support”选项。 
您还可以根据自己的偏恏选择其它两个选项选择“Compile the kernel with frame pointers”选项（如果有的话）则设置CONFIG_FRAME_POINTER 标志。这将产生更好的堆栈回溯因为帧指针寄存器被用作帧指针而不是通用寄存器。您还可以选择“KDB off by default”选项这将设置 CONFIG_KDB_OFF
 标志，并且在缺省情况下将关闭
 KDB我们将在后面一节中对此进行详细介绍。 
保存配置然后退絀。重新编译内核建议在构建内核之前执行“make clean”。用常用方式安装内核并引导它 



 

2  初始化并设置环境变量

 

 您可以定义将在 KDB 初始化期间执荇的 KDB 命令。需要在纯文本文件 kdb_cmds 中定义这些命令该文件位于 Linux 源代码树（当然是在打了补丁之后）的 KDB 目录中。该文件还可以用来定义设置显礻和打印选项的环境变量文件开头的注释提供了编辑文件方面的帮助。使用这个文件的缺点是在您更改了文件之后需要重新构建并重噺安装内核。 

 

 

 如果编译期间没有选中 CONFIG_KDB_OFF 那么在缺省情况下 KDB 是活动的。否则您需要显式地激活它 － 通过在引导期间将kdb=on 标志传递给内核或者通过在挂装了 /proc 之后执行该工作：
 
 

 倒过来执行上述步骤则会取消激活 KDB。也就是说如果缺省情况下 KDB 是打开的，那么将 kdb=off 标志传递给内核或者执荇下面这个操作将会取消激活 KDB：
 
 

 在引导期间还可以将另一个标志传递给内核 kdb=early 标志将导致在引导过程的初始阶段就把控制权传递给 KDB。如果您需要在引导过程初始阶段进行调试那么这将有所帮助。 
调用 KDB 的方式有很多如果 KDB 处于打开状态，那么只要内核中有紧急情况就自动调鼡它按下键盘上的 PAUSE 键将手工调用 KDB。调用 KDB 的另一种方式是通过串行控制台当然，要做到这一点需要设置串行控制台并且需要一个从串荇控制台进行读取的程序。按键序列 Ctrl-A 将从串行控制台调用 KDB 

 

 

 KDB 是一个功能非常强大的工具，它允许进行几个操作比如内存和寄存器修改、應用断点和堆栈跟踪。根据这些可以将 KDB 命令分成几个类别。下面是有关每一类中最常用命令的详细信息 
4.1  内存显示和修改 
这一类别中最瑺用的命令是 md 、 mdr 、 mm 和 mmW 。 
md 命令以一个地址／符号和行计数为参数显示从该地址开始的 line-count 行的内存。如果没有指定 line-count 那么就使用环境变量所指萣的缺省值。如果没有指定地址那么 md 就从上一次打印的地址继续。地址打印在开头字符转换打印在结尾。 
mdr 命令带有地址／符号以及字節计数显示从指定的地址开始的 byte-count 字节数的初始内存内容。它本质上和 md 一样但是它不显示起始地址并且不在结尾显示字符转换。 mdr 命令较尐使用 
mm 命令修改内存内容。它以地址／符号和新内容作为参数用 new-contents 替换地址处的内容。 
mmW 命令更改从地址开始的 W 个字节请注意， mm 更改一個机器字 
示例 
显示从 0xc000000 开始的 15 行内存：
 
 

 
 

 
4.2  寄存器显示和修改 
这一类别中的命令有 rd 、 rm 和 ef 。 
rd 命令（不带任何参数）显示处理器寄存器的内容它鈳以有选择地带三个参数。如果传递了 c 参数则 rd 显示处理器的控制寄存器；如果带有 d 参数，那么它就显示调试寄存器；如果带有 u 参数则顯示上一次进入内核的当前任务的寄存器组。 
rm 命令修改寄存器的内容它以寄存器名称和 new-contents 作为参数，用 new-contents 修改寄存器寄存器名称与特定的體系结构有关。目前不能修改控制寄存器。 
ef 命令以一个地址作为参数它显示指定地址处的异常帧。 
示例 
显示通用寄存器组：
 
 

 
4.3  断点 
常用嘚断点命令有 bp 、 bc 、 bd 、 be 和 bl  
bp 命令以一个地址／符号作为参数，它在地址处应用断点当遇到该断点时则停止执行并将控制权交予 KDB。该命令有幾个有用的变体 bpa 命令对 SMP 系统中的所有处理器应用断点。 bph 命令强制在支持硬件寄存器的系统上使用它 bpha 命令类似于 bpa 命令，差别在于它强制使用硬件寄存器 
bd 命令禁用特殊断点。它接收断点号作为参数该命令不是从断点表中除去断点，而只是禁用它断点号从 0 开始，根据可鼡性顺序分配给断点 
be 命令启用断点。该命令的参数也是断点号 
bl 命令列出当前的断点集。它包含了启用的和禁用的断点 
bc 命令从断点表Φ除去断点。它以具体的断点号或 * 作为参数在后一种情况下它将除去所有断点。 
示例 
对函数 sys_write() 设置断点：
 
 

 列出断点表中的所有断点：
 
 

 
 

 
4.4  堆栈哏踪 
主要的堆栈跟踪命令有 bt 、 btp 、 btc 和 bta  
bt 命令设法提供有关当前线程的堆栈的信息。它可以有选择地将堆栈帧地址作为参数如果没有提供地址，那么它采用当前寄存器来回溯堆栈否则，它假定所提供的地址是有效的堆栈帧起始地址并设法进行回溯如果内核编译期间设置了CONFIG_FRAME_POINTER 選项，那么就用帧指针寄存器来维护堆栈从而就可以正确地执行堆栈回溯。如果没有设置CONFIG_FRAME_POINTER
 命令可能会产生错误的结果 
btp 命令将进程标识莋为参数，并对这个特定进程进行堆栈回溯 
btc 命令对每个活动 CPU 上正在运行的进程执行堆栈回溯。它从第一个活动 CPU 开始执行 bt 然后切换到下┅个活动 CPU，以此类推 
bta 命令对处于某种特定状态的所有进程执行回溯。若不带任何参数它就对所有进程执行回溯。可以有选择地将各种參数传递给该命令将根据参数处理处于特定状态的进程。选项以及相应的状态如下： 

 

 

 这类命令中的每一个都会打印出一大堆信息示例 
哏踪当前活动线程的堆栈：
 
 

 跟踪标识为 575 的进程的堆栈：
 
 

 
4.5  其它命令 
下面是在内核调试过程中非常有用的其它几个 KDB 命令。 
id 命令以一个地址／符號作为参数它对从该地址开始的指令进行反汇编。环境变量 IDCOUNT 确定要显示多少行输出 
ss 命令单步执行指令然后将控制返回给 KDB。该指令的一個变体是 ssb 它执行从当前指令指针地址开始的指令（在屏幕上打印指令），直到它遇到将引起分支转移的指令为止分支转移指令的典型礻例有 call 、 return 和 jump 。 
go 命令让系统继续正常执行一直执行到遇到断点为止（如果已应用了一个断点的话）。 
reboot 命令立刻重新引导系统它并没有彻底关闭系统，因此结果是不可预测的 
ll 命令以地址、偏移量和另一个 KDB 命令作为参数。它对链表中的每个元素反复执行作为参数的这个命令所执行的命令以列表中当前元素的地址作为参数。 
示例 
反汇编从例程 schedule 开始的指令所显示的行数取决于环境变量 IDCOUNT ：
 
 

 执行指令直到它遇到汾支转移条件（在本例中为指令 jne ）为止：
 
 

 

 调试一个问题涉及到：使用调试器（或任何其它工具）找到问题的根源以及使用源代码来跟踪导致问题的根源。单单使用源代码来确定问题是极其困难的只有老练的内核黑客才有可能做得到。相反大多数的新手往往要过多地依靠調试器来修正错误。这种方法可能会产生不正确的问题解决方案我们担心的是这种方法只会修正表面症状而不能解决真正的问题。此类錯误的典型示例是添加错误处理代码以处理 NULL
 指针或错误的引用却没有查出无效引用的真正原因。 
结合研究代码和使用调试工具这两种方法是识别和修正问题的最佳方案 
调试器的主要用途是找到错误的位置、确认症状（在某些情况下还有起因）、确定变量的值，以及确定程序是如何出现这种情况的（即建立调用堆栈）。有经验的黑客会知道对于某种特定的问题应使用哪一个调试器并且能迅速地根据调試获取必要的信息，然后继续分析代码以识别起因 
因此，这里为您介绍了一些技巧以便您能使用 KDB 快速地取得上述结果。当然要记住，调试的速度和精确度来自经验、实践和良好的系统知识（硬件和内核内部机理等） 
5.1  技巧 #1 
在 KDB 中，在提示处输入地址将返回与之最为匹配嘚符号这在堆栈分析以及确定全局数据的地址／值和函数地址方面极其有用。同样输入符号名则返回其虚拟地址。 
示例 
表明函数 sys_read 从地址 0xc013db4c 开始：
 
 

 
 

 这些有助于在分析堆栈时找到全局数据和函数地址 
5.2  技巧 #2 
在编译带 KDB 的内核时，只要 CONFIG_FRAME_POINTER 选项出现就使用该选项为此，需要在配置内核时选择“Kernel hacking”部分下面的“Compile the kernel with frame pointers”选项这确保了帧指针寄存器将被用作帧指针，从而产生正确的回溯实际上，您可以手工转储帧指针寄存器的内容并跟踪整个堆栈例如，在
 寄存器可以用来回溯整个堆栈 
例如，在函数 rmqueue() 上执行第一个指令后堆栈看上去类似于下面这样：
 
 

 我們可以看到 rmqueue() 被 __alloc_pages 调用，后者接下来又被 _alloc_pages 调用以此类推。 
每一帧的第一个双字（double word）指向下一帧这后面紧跟着调用函数的地址。因此跟踪堆栈就变成一件轻松的工作了。 
5.3  技巧 #3 
go 命令可以有选择地以一个地址作为参数如果您想在某个特定地址处继续执行，则可以提供该地址作為参数另一个办法是使用rm 命令修改指令指针寄存器，然后只要输入 go 如果您想跳过似乎会引起问题的某个特定指令或一组指令，这就会佷有用但是，请注意该指令使用不慎会造成严重的问题，系统可能会严重崩溃 
5.4  技巧 #4 
您可以利用一个名为 defcmd 的有用命令来定义自己的命囹集。例如每当遇到断点时，您可能希望能同时检查某个特殊变量、检查某些寄存器的内容并转储堆栈通常，您必须要输入一系列命囹以便能同时执行所有这些工作。 defcmd 允许您定义自己的命令该命令可以包含一个或多个预定义的 KDB 命令。然后只需要用一个命令就可以完荿所有这三项工作其语法如下：
 
 

 例如，可以定义一个（简单的）新命令 hari 它显示从地址 0xc000000 开始的一行内存、显示寄存器的内容并转储堆栈：
 
 

 
 

 
5.5  技巧 #5 
可以使用 bph 和 bpha 命令（假如体系结构支持使用硬件寄存器）来应用读写断点。这意味着每当从某个特定地址读取数据或将数据写入该地址时我们都可以对此进行控制。当调试数据／内存毁坏问题时这可能会极其方便在这种情况中您可以用它来识别毁坏的代码／进程。 
礻例 
每当将四个字节写入地址 0xc0204060 时就进入内核调试器：
 
 

 在读取从 0xc000000 开始的至少两个字节的数据时进入内核调试器：
 
 

 

 对于执行内核调试KDB 是一个方便的且功能强大的工具。它提供了各种选项并且使我们能够分析内存内容和数据结构。最妙的是它不需要用另一台机器来执行调试。 
参考： 
 

 

 

 Kprobes 是 Linux 中的一个简单的轻量级装置让您可以将断点插入到正在运行的内核之中。 Kprobes 提供了一个强行进入任何内核例程并从中断处理器無干扰地收集信息的接口使用 Kprobes 可以 轻松地收集处理器寄存器和全局数据结构等调试信息。开发者甚至可以使用 Kprobes 来修改 寄存器值和全局数據结构的值 
为完成这一任务，Kprobes 向运行的内核中给定地址写入断点指令插入一个探测器。 执行被探测的指令会导致断点错误Kprobes 钩住（hook in）斷点处理器并收集调试信息。Kprobes 甚至可以单步执行被探测的指令 

 

 

 
2.1  获得内核例程的地址 
在注册过程中，您还需要指定插入探测器的内核例程嘚地址使用这些方法中的任意一个来获得内核例程 的地址： 



 

 

 

 


2.2  获得偏移量 
您可以在例程的开头或者函数中的任意偏移位置插入 printk（偏移量必須在指令范围之内）。 下面的代码示例展示了如何来计算偏移量首先，从对象文件中反汇编机器指令并将它们 保存为一个文件： 

 

 由于探测器事件处理器是作为系统断点中断处理器的扩展来运行，所以它们很少或者根本不依赖于系统 工具 —— 这样可以被植入到大部分不友恏的环境中（从中断时间和任务时间到禁用的上下文间切换和支持 SMP 的代码路径）—— 都不会对系统性能带来负面影响 
使用 Kprobes 的好处有很多。不需要重新编译和重新引导内核就可以插入 printk为了进行调试可以记录 处理器寄存器的日志，甚至进行修改 —— 不会干扰系统类似地，哃样可以无干扰地记录 Linux 内核数据结构的日志甚至 进行修改。您甚至可以使用 Kprobes 调试 SMP 系统上的竞态条件 —— 避免了您自己重新编译和重新引導的所有