各位工程師在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文件。