各位工程师在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模块时错误，对应于读取操作者insmodmxs＿bl．ko。

3PC指针用作提醒错误时的PC指针方位，PC指针即当前程序运行点的地址，这里提醒回应错误函数为regulator＿set＿current＿limit，位移地址为0xc。4LR指针用作提醒错误时的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，即在内核源码范围内。

本文来源：NG体育-www.louissgd.com