第十八章 调试
一、内核中的bug
内核bug的原因可能有：
- 错误代码
- 同步时发生的错误，例如共享变量锁定不当
- 错误的管理硬件
- ……内核bug发作的症状可能有：
- 降低所有程序的运行性能
- 毁坏数据
- 使得系统处于死锁状态
- ……内核开发比起用户开发要多考虑一些独特的问题，比如：
- 定时限制
- 竞争条件
- ……
原因是允许多个线程在内核中同时运行。二、通过打印来调试
1. 健壮性
- 弹性极佳的函数：任何时候、任何地方都能调用它
- 可以在中断上下文和进程上下文中被调用
- 可以在任何持有锁时被调用
- 可以在多处理器上同时被调用
- 除非再启动过程中的初期就要在终端上输出
2. 日志等级
printk()和printf()在使用上最主要的区别就是前者可以指定一个日志级别。内核通过这个级别来判断是否在终端上打印消息。- 内核把级别比某个特定值低的所有消息显示在终端上。
- 如果没有指定一个记录等级，函数会选用默认的
DEFAULT_MASSAGE_LOGLEVEL。 - 内核会把这些记录等级转化，n指等级，从0-7，对应表中从上到下，数字越小越重要。
0 KERN_EMERG 最重要 7 KERN_DEBUG 最不重要 - 调试信息， 有两种赋予记录等级的方法：
-
- 保持终端的默认记录等级不变，给所有调试信息KERN_CRIT或更低的等级。
- 给所有调试信息KERN_DEBUG等级，调整终端的默认记录等级。
-
- printk的输出日志级别如下:
| 等级 | 描述 |
|---|---|
| KERN_ EMERG | 一个紧急情况 |
| KERN_ ALERT | 一个需要立即被注意到的错误 |
| KERN_ CRIT | 一个临界情况 |
| KERN_ ERR | 一个错误 |
| KERN_ WARNING | 一个警告 |
| KERN_ NOTICE | 一个普通的, 不过也有可能需要注意的情况 |
| KERN_ INFO | 一条非正式的消息 |
| KERN_ DEBUG | 一条调试信息--一般是冗余信息 |
3. 缓冲区
- 内核消息都被记录在环形队列中，以队列方式进行读写；大小可以通过设置CONFIGLOGBUF_SHIFT进行调整
- 在单处理器上，该缓冲区大小默认为16KB，也就是说，超过的消息将覆盖旧消息
- 优势：
- 读写同步问题容易解决
- 记录的维护更加方便
4. 相关进程
- 用户空间的守护进程——klogd从记录缓冲区中读取内核信息，再通过syslogd守护进程将它们保存在系统日志文件中
- klogd会阻塞知道==直到有新的内核消息可供读出。被唤醒之后，它会读出新的内核消息并进行处理（默认情况下，就是传递给syslogd）；
- syslogd会将所有接收到的消息添加到（默认情况下是messages）文件中
三、oops
oops是内核告知用户有不幸发生的最常用的方式。
内核很难自我修复，也不能将自己杀死，只能发布oops，过程包括：
- 向终端上输出错误消息
- 输出寄存器中保存的信息
- 输出可供跟踪的回溯线索通常发送完oops之后，内核会处于一种不稳定状态。
关于oops发生的时机：
- 发生在中断上下文：内核无法继续，会陷入混乱，导致系统死机
- 发生在idle进程或init进程（0号进程和1号进程），同上
- 发生在其他进程运行时，内核会杀死该进程并尝试着继续执行
内和调试配置项：
- 配置项：CONFIGDEBUGKERNEL
- 选项 之 sleep-inside-spinlockchecking（自旋锁内睡眠选项）——正在使用自旋锁或者禁止抢占的代码进行的是原子操作，不可更改
- 探测范围：
- 正在使用锁的时候调用schedule();
- 正使用锁的时候以阻塞方式请求分配内存；
- 引用单CPU数据时睡眠
引发bug并打印信息：
- 利用BUG()以及BUG_ON（）（因为大多数体系结构都把这两个函数定义成某种非法操作，可以触发oops）
- 当做断言或者条件语句
- 调用panic()函数会在打印错误信息的同时挂起系统
- panic("terrible thing"，terrible_thing)；
- 调用dump_stack()，只在终端上打印寄存器上下文及函数的跟踪线索
系统请求键
- 配置项：CONFIGMAGICSYSR配置选项来启动；此外，通过/proc/sys/kernel/sysrq标记该特性的开关
- 优点：无论内核处于什么状态，都可以通过特殊的组合键跟内核进行通信
- 常见的命令
- SysRq-b:重启设备
- SysRq-o:关闭机器
- SysRq-u:卸载所有的文件系统
- SysRq-s:把所有已安装的文件系统都刷新到磁盘
oops中包含的重要信息：寄存器上下文和回溯线索
- 回溯线索：显示了导致错误发生的函数调用链。
- 寄存器上下文信息也很有用，比如帮助冲进引发问题的现场
-
-
ksymoops
-
回溯线索中的地址需要转化成有意义的符号名称
——需要调用ksymoops命令。
并且还必须提供编译内核时产生的System.map。如果用的是模块，还需要一些模块信息。
kysmoop saved_oops.txt-
-
kallsyms
-
现在的版本中不需要使用sysmoops这个工具，因为可能会发生很多问题，新版本中引入了kallsyms疼，可以通过定义CONFIG_KALLSYMS配置选项启用。
四、内核调试器
1.gdb
可以使用标准的GNU调试器对正在运行的内核进行查看。
针对内核启动调试器的方法与针对进程的方法大致相同：
gdb vmlinux /proc/kcore
vmlinx:未经压缩的内核映像，区别于zImage或bImage，它存放于源代码树的根目录上。
/proc/kcore作为一个参数选项，是作为core文件来用的，通过它能够访问到内核驻留的高端内存。只有超级用户才能读取此文件的数据可以使用gdb的所有命令来获取信息。例如：
打印一个变量的值：
p global_variable
反汇编一个函数：
disassemble function
-g参数还可以提供更多的信息。局限性：
- 没有办法修改内核数据
- 不能单步执行内核代码
2.kgdb
是一个补丁 ，可以让我们在远程主机上通过串口利用gdb的所有功能对内核进行调试。
需要两台计算机：仪态运行带有kgdb补丁的内核，第二胎通过串行线使用gdb对第一台进行调试。
通过kgdb，gdb的所有功能都能使用:
- 读取和修改变量值
- 设置断点
- 设置关注变量
- 单步执行五、探测系统
1.使用uid作为选择条件
一般情况下，加入特性时，只要保留原有的算法而把新算法加入到其他位置上，基本就能保证安全。
可以把用户id（UID）作为选择条件来实现这种功能：
通过某种选择条件，安排到底执行哪种算法。
例如：
if (current-> uid !=7777) {
/* 老算法…… */
} else {
/* 新算法…… */
}即，除了uid=7777的用户以外，其他所有的用户都是用的老算法，所以这个7777用户可以专门用来测试新算法。
2.使用条件变量
如果代码与进程无关，或者希望有一个针对所有情况都能使用的机制来控制某个特性，可以使用条件变量。
这种方式比使用UID更简单，只需要创建一个全局变量作为一个条件选择开关：
- 如果该变量为0，就使用某一个分支上的代码；
- 否则，选择另外一个分支。
操控方式：某种接口，或者调试器。
3.使用统计量
这种方法常用于使用者需要掌握某个特定事件的发生规律的时候。
方法是创建统计量，并提供某种机制访问其统计结果。
4.重复频率限制
当系统的调试信息过多的时候，有两种方式可以防止这类问题发生：
- 重复频率限制
- 发生次数限制