各位工程师在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，即在内核源码范围内。
