各位工程师在 Linux 下开发程序时，有没有遇到由于系统中存在某些小故障而跳出了“Oops”提示的情况，此时你是如何排查故障？一行行的查看代码吗？其实不用那么复杂，本文将为你介绍一种高效的 Linux 编程的故障排除方法。
 
在分析 Oops 之前，我们先来看以下这么一个例子，使用 GPIO 的中断做掉电检测，参考《嵌入式 Linux 开发教程下册》的驱动框架，设计如下程序框图：
 
 
这个框架设计之初的理想流程为：应用启动 ->程序初始化 ->应用 open 设备 ->等待中断事件，但实际项目开发时，往往发生许许多多不可预测的事情。如小王正在调 Qt 应用，发现老王的进程老在打印，那就不让老王的进程开机自启动，调了两三天后，不定时地提示个 Oops 提示，小王按照“以前代码不出现，新加的出现，那么起因绝对在新代码内”的惯性思维，认为是新加的 Qt 导致的，然后小王就不断测试，不断查找 bug 中 ....... 这样就过去了十年。
 
但原因其实是小王没有 open 设备，即驱动层没有初始化定时器队列，那么中断处理函数中 50ms 触发的队列就为一个空值，空指针时 Linux 内核当然“哎呦”一下提醒你了，而不定时地提示其实就是因为电源不定时地松动，gpio 检测到掉电了所以触发了中断。
 
实际上，这样的案例十分常见，原本想 A->B->C，实际使用是 A->D->C，又或者驱动中有某个变量忘记初始化等等，这时分析 Oops 就可以十分快速地解决问题。那接下来我们就用 Linux 中标准驱动去触发一个 Oops，对的你没看错，Linux 内核标准源码也存在这样的异常，而且我们也可以去修复这样的问题。
 
使用我司的 EasyARM-iMX283 开发板，内核源码为光盘内的 Linux-2.6.35.3.tar.bz2，编译方法请参考光盘资料，我们需要把 lcd 的背光驱动修改为 ko 模式。
 
 
烧录完新内核，加载新编译出来的 drivers/video/backlight/mxs_bl.ko 文件就会提示以下 Oops 信息：
 
 
乍看之下，这段信息跟乱码差不多，但只要你一层层地分析，你就会发现，这些信息已经告诉了我们错误的原因。接下来就开始我们的 Oops 分析之旅。
 
1、主要错误信息
 
 
用于提示错误的类型，这里表示使用空指针。
 
2、操作入口
 
 
用于提示错误的操作，这里表示加载 mxs_bl 模块时出错，对应于加载操作 insmod mxs_bl.ko。
 
3、PC 指针
 
 
用于提示出错时的 PC 指针位置，PC 指针即当前程序运行点的地址，这里提示表示错误函数为 regulator_set_current_limit，偏移地址为 0xc。
 
4、LR 指针
 
 
用于提示出错时的 LR 指针位置，LR 指针即调用子函数的上一个函数名以及入口偏移量，这里表示上一个函数为 set_bl_intensity，偏移地址为 0xd8。即 set_bl_intensity 调用 regulator_set_current_limit 时出错。
 
5、寄存器值
 
 
用于记录出错时各个寄存器的值，对于汇编比较熟悉的同志们可以研究一下这段信息。
 
6、出错进程信息
 
 
用于提示出错的进程 id 号与进程名称。出错进程为 insmod， PID 号 2261，对于多任务系统中，可能存在多个 PID 调用同一个接口的情况。
 
7、出错时的堆栈信息
 
 
用于提示出错时堆栈内保存的寄存器信息，当程序由于中断发生或子程序调用时，会执行压栈操作，即将运行环境保存到堆栈内，保证退出中断或跳出子程序后，运行环境不发生改变。
 
而此处的堆栈信息即记录了程序运行时的环境信息。从中我们可以找到许多 LR 地址，从而分析出函数调用关系，与下一段的信息有类似作用。
 
8、函数执行的回溯关系
 
 
用于表示函数的调用关系，通过这段信息我们可以知道，函数的整个执行流程，知道它的函数调用关系，最后整理出来的函数执行流程如下：
 
 
从中我们看到了熟悉的 init 函数、probe 函数、以及清楚 probe 函数下执行的操作过程是到哪一步出错的。现在我们知道了代码的执行流程，出错的 PC 指针的位置，但还是看不到代码，出错指针处我们只看到了一串数字，那么接下来我们就操作一下，把 pc 指针的数据变为有意义的代码。

 

 
第一步，分辨出错误代码在什么位置
 
这次实验涉及的二进制文件有内核的烧录固件以及驱动的 ko 文件，所以第一步分析就需要确定出错代码是在内核固件里还是 ko 文件里。
 
首先得到内核代码的范围，用以下命令将内核反汇编。
 
 
查看这个文件的格式如是：
 
 
第一列行数，第二列运行地址，第三列二进制码，第四列汇编代码，既然第二列为运行地址，即等同于程序运行到这行时，pc 指针的值等于这个数值。这样只要翻看这个文件的头部以及尾部，就能知道内核代码的 PC 指针范围为：c0008000~c0562338。
根据前面第 5 步寄存器值，出错时 PC 指针为 c02f1878，即在内核源码范围内。
 
第二步，分析出错函数的出错语句
 
那么根据第 3 步 PC 指针，得到 regulator_set_current_limit 的汇编代码，如下：
 
 
函数入口地址为 c02f186c 。
 
在第 3 步 PC 指针指出偏移地址为“PC is at regulator_set_current_limit+0xc”。
 
PC = 0xc02f1878 = 0xc02f186c + 0xc，符合汇编代码地址。
 
第三步，找到出错函数的 C 语言代码
 
这步可以说是最困难的，因为内核代码层次多，同名函数也可能存在许多份，可能几份编译进内核（static 声明的局部函数），也可能没编译进内核，如何从众多的代码中分析出具体哪段呢。
 
本人就使用了一些小手段，首先给每个同名函数的入口加段乱码，让编译器筛选出编译进内核的文件（因为乱码，所以编译会报错），然后给剩下的函数加打印语句，通常经过第一步之后，可选的目标就两三个，通过打印进一步确认代码即可。
 
以下为筛选出来的 C 语言代码。
 
 
看到这好像是定位了函数，但对于不熟悉汇编的人来说，C 与汇编还是没有关联起来，好像进入了死胡同，但先别气馁，从上面的汇编代码中我们知道，函数名即为函数的首地址，那么调用子函数即需要让 CPU 知道子函数名，那么汇编如何调用子函数呢？使用 bl 指令， bl+子函数名。既然汇编有这么一个特性，那么我们看汇编代码。
 
上面 582734 行为“bl  c0493104 ”这句调用了子函数，再看 C 中调用此函数的语句。
 
 
那么结果显而易见，不可能定义个变量都报错吧，所以唯一可能错误的语句就是 struct regulator_dev *rdev = regulator->rdev，同理，这句的前半部也只是定义一个 rdev 的变量，再结合内核给出来的提示——空指针，所以错误就是 regulator->rdev 是一个空指针。
 
最终的问题就归结于，为什么 regulatar->rdev 为空指针。这部分的查阅代码以及推理需要更深层次地挖掘，工作量也非本文能说清的，故作者在这里就大胆地推测与上面的 A->B->C 模型类似。所以我们就需要在这个资源存在的时刻，调用它之前给它赋值。
这时侯，我们就需要拿出第 8 步函数执行的回溯关系图，既然知道这个图中最后的函数的输入参数 regulator 的 rdev 为空，那么我们就关心 regulator 结构体以及它的意义。从结构体的意义我们才能知道如何给它赋值。
 
 
在相关的代码文件中搜索关键字”regulator”或”regulator =”（建议搜这个，因为这种才是赋值语句）得到如下代码。
 
   
 
分析这个函数可知，regulator 实际是 pdata 的一个成员，他需要 data 来初始化，那么接下来的事情就简单了，在回溯关系中找一个位置把 data 的数据塞入 pdata 中，刚好这段函数就是初始化的 regulator 的，那就直接拿去用吧。
 
把这段添加到 probe 函数内的这个位置，实现了在 mxsbl_probe 和 mxsbl_do_probe 之间赋值此变量。
 
 
这样重新编译后即可正常加载 ko 文件。