《Linux内核设计与实现》 第五周 读书笔记（第十八章）

第18章 调试

20135307张嘉琪

---

18.1　准备开始

18.2　内核中的bug

• 内核中的bug多种多样，它们的产生能够有无数的缘由，同时它们的表象也变化无穷，从明白无误的错误代码（好比，没有把正确的值存放在恰当的位置）到同步时发生的错误（好比共享变量锁定不当）再到错误地管理硬件（好比，给错误的控制寄存器发送错误的指令）。从下降全部程序的运行性能到毁坏数据再到使得系统处于死锁状态，均可能是bug发做时的症状。

18.3　经过打印来调试

18.3.1　健壮性

• 健壮性是printk()函数最容易让人们接受的一个特质。任什么时候候，任何地方都能调用它，内核中的printk()比比皆是。它是一个弹性极佳的函数，这一点至关重要。printk()之因此这么有用，就在于它随时都能被调用。printk()函数的健壮躯壳下也不免会有漏洞，在系统启动过程当中．终端尚未初始化以前在某些地方不能使用它。不过说实在的，若是终端没有初始化，你又能输出到什么地方去呢？这―般不是一个什么问题。除非你要调试的是启动过程最开始的那些步骤（好比说在负责执行硬件体系结构相关的初始化动做的函数中）下进行这样的调试挑战性很强没有任何打印函数能用，确实让问题更加棘手。

18.3.2　日志等级

• printk()和printf()在使用上最主要的区别就是前者能够指定一个日志级别。

• 内核根据这个级别来判断是否在终端上打印消息。

• 内核把级别比某个特定值低的全部消息显示在终端上。

18.3.3　记录缓冲区

• 内核消息都被保存在一个LOGBUFLEN大小的环形队列中。该缓冲区大小能够在编译时经过设置CONFIG_LOGBUFSHIFT进行调整。在单处理器的系统上其默认值是16KB。换句话说，就是内核在同一时间只能保存16KB的内核消息。若是消息队列已经达到最大值，那么若是再有printk()调用时，新消息将覆盖队列中的老消息。这个记录缓冲区之因此称为环形是由于它的读写都是按照环形队列方式进行操做的。

• 使用环形队列有许多好处。因为同时读写环形缓冲区时，其同步问题很容易解决，因此即便在中断上下文中也能够方便地使用printfk()。此外，它使记录维护起来也更容易。若是有大量的消息同时产生，新消息只需覆盖掉旧消息便可。在某个问题引起大量消息的时候。记录只会覆盖掉它自己，而不会由于失控而消耗掉大量内存。而环形缓冲区的惟一缺点——可能会丢失消息可是与简单性和健壮性的好处相比这点代价是值得的。

18.3.4　syslogd和klogd

• 在标准的Linux系统上，用户空间的守护进程klogd从记录缓冲区中获取内核消息，再经过syslogd守护进程将它们保存在系统日志文件中，klogd程序既能够从/proc/kmsg文件中，也能够经过syslog()系统调用读取这些消息，默认状况下，它选择读取/proc方式实现，无论是哪一种方法，klogd都会阻塞，直到有新的内核消息可供读出。在被唤醒以后，它会读取出新的内核消息并进行处理，默认状况下，它就是把消息传给syslogd守护进程。

18.3.5　从printf()到printk()的转换

18.4　oops

• oops是内核告知用户有不行法神最经常使用的方式。

• oops中包含的重要信息对于全部体系结构都是彻底相同的：寄存器上下文和回溯线索。

• 回溯线索显示了致使错误发生的函数调用链。这样咱们就能够观察究竟发生了什么：机器处于空闲状态，正在执行idle循环，由cpuidle()循环调用defaultidle()。此时定时器中断产生了，它引发了对定时器的处理，tulip_timer()这个定时器处理函数被调用，而就是它引用了空指针。甚至能够经过偏移量找出致使问题的语句。

18.4.1　ksymoops

• 回溯线索中的地址须要转化成有意义的符号名称才方便使用，这须要调用ksymoops命令。而且还必须提供编译内核时产生的System.map。若是使用的是模块，还须要一些模块信息。

18.4.2　kallsyms

• 配置选项CONFIG＿KALLSYMS_ALL 表示不只存放函数名称，还存放全部的符号名称。

18.5　内核调试配置选项

• 在编译的时候，为了方便调试和测试内核代码，内核提供了许多配置选项。在内核配置编辑器的内核开发菜单。这些选项中，它们都依赖于CONFIGDEBUGKERNEL。

18.6　引起bug并打印信息

• 一些内核调用能够用来方便标记bug方便标记bug提供断言并输出信息。最经常使用的两个是BUG()和些声明BUG_ON()。当被调用的时候，它们会引起oops,致使栈的回溯和错误信息的打印。大部分体系结构把BUG()和BUG＿ON()定义成某种会致使oops跟硬件的体系结构是相关的非法操做，这样天然会产生须要的oops。能够把这些调用当作断言使用，想要断言某种状况不应发生。

• 18.7　神奇的系统请求键

• 系统请求键功能能够经过定义CONFIGMAGICSYSRQ配置选项来启用。

• 当该功能被启用的时候，不管内核处于什么状态，均可以经过特殊的组合键跟内核进行通讯。这种功能可让你在面对一台奄奄一息的系统时能完成一些有用的工做。除了配置选项之外，还要经过一个sysctl用来标记该特性的开或关。

• 须要启用它时使用以下命令:echo 1> /proc/sys/kernel/sysrq

18.8　内核调试器的传奇

• 不少内核开发者一直以来都但愿能拥有一个用于内核的调试器.不幸的是，Linus不肯意在它的内核源代码树中加入一个调试器。他认为调试器会误导开发者，从而致引入不良的修正，没有人能对他的逻辑提出异议从真正理解代码出发，确实更能保证修正的正确性。然而，许多内核开发者们仍是但愿有一个官方发布的、用于内核的调试器。由于这个要求看起来不会立刻被知足，因此许多补丁应运而生了，它们为标准内核附加上了内核调试的支持，虽然这都是―些不被官方承认的附加补丁，但它们确实功能完善，十分强大。在咱们深刻这些解决方案以前，先看看标准的调试器gdb可以给咱们一些什么帮助是―个不错的选择。

18.8.1　gdb

18.8.2　kgdb

• kgdb是一个补丁，它可让咱们在远端主机上经过串口利用gdb的全部功能对内核进行调试。这须要两台计算机：第一台运行带有kgdb补丁的内核，第二台经过串行线使用gdb对第一台进行调试。经过kgdb的全部功能都能使用：读取或修改变量值，设置断点，设置关注变量，单步执行等。某些版本的gdb甚至容许执行函数。设置kgdb和链接串行线比较麻烦，可是一旦作完了，调试就变得很简单了。

18.9　探测系统

。

18.9.1　用UID做为选择条件

• 假设为了加入一个激动人心的新特性，你重写了fork()系统调用。除非第一次的尝试就天衣无缝，不然系统调试就是―场噩梦。如fork()系统调用不正常的话，压根就不用期望整个系统还能正常工做。固然，和任什么时候候同样，但愿老是存在的，通常状况下，只要保留原有的算法而把你的新算法加入到其余位置上，基本就能保证安全：能够利用把用户id做为选择条件来实现这种功能，经过这种选择条件，能够安排到底执行哪一种算法。

18.9.2　使用条件变量

• 若是代码与进程无关，或者但愿有一个针对全部状况都能使用的机制来控制某个特性，可使用条件变量。这比使用UID还来得简单，只须要建立一个全局变量做为一个条件选择开关。若是该变量为零，就使用一个分支上的代码。若是它不为零，就选择另一个分支。能够经过某种接口提供对这个变量的操控，也能够直接经过调试器进行操控。

18.9.3　使用统计量

• 有些时候你须要掌握某个特定事件的发生规律。有些时候须要比较多个事件并从中得出规律。经过建立统计量并提供某种机制访问其统计结果，很容易就能知足这种需求。举个例子，假设咱们但愿获得foo和bar的发生频率，那么在某个文件中，固然最好是在定义该事件的那个文件里定义两个全局变量。

18.9.4　重复频率限制

18.10　用二分查找法找出引起罪恶的变动

18.11　使用Git进行二分搜索

• Git源码管理工具提供了一个有用的二分搜索机制。若是你使用Git来控制Linux源码树的副本，那么Git将自动运行二分搜索进程。此外，Git会在修订版本中进行二分搜索，这样能够找到具体哪次提交的代码引起了bug。不少Git相关的任务比较繁杂，但使用Git进行二分搜索并不那么的困难。

18.12　当全部的努力都失败时：社区

• 或许你已经作完了全部你能想到的尝试，你在键盘上呕心沥血了几个小时。实际上，多是无很多天子，答案依旧没有眷顾你。此时，若是bug是在Linux内核的主流部分中，你能够在内核开发社区中寻求其余开发者的帮助你应该向内核邮件列表发送一份电子邮件，对bug进行完整而又简洁地描述，你的发现可能会对找到最终的答案起到帮助。

18.13　小结

• 本章讨论了内核的调试。调试过程实际上是一种寻求实现与目标误差的行为，咱们考察了几种技术：从内核内置的调试架构到调试程序，从记录日志到用git二分法查找，由于调试Linux内核困难重重，非调试用户程序能比，所以，本章的资料对于试图在内核代码中牛刀小试的任何人都相当重要。