Linux編程時(shí)遇到Oops提示該如何排查？

各位工程師在Linux下開發(fā)程序時(shí)，有沒有遇到由于系統(tǒng)中存在某些小故障而跳出了“Oops”提示的情況，此時(shí)你是如何排查故障？一行行的查看代碼嗎？其實(shí)不用那么復(fù)雜，本文將為你介紹一種高效的Linux編程的故障排除方法。

在分析Oops之前，我們先來看以下這么一個(gè)例子，使用GPIO的中斷做掉電檢測(cè)，參考《嵌入式Linux開發(fā)教程下冊(cè)》的驅(qū)動(dòng)框架，設(shè)計(jì)如下程序框圖：

這個(gè)框架設(shè)計(jì)之初的理想流程為：應(yīng)用啟動(dòng)-》程序初始化-》應(yīng)用open設(shè)備-》等待中斷事件，但實(shí)際項(xiàng)目開發(fā)時(shí)，往往發(fā)生許許多多不可預(yù)測(cè)的事情。如小王正在調(diào)Qt應(yīng)用，發(fā)現(xiàn)老王的進(jìn)程老在打印，那就不讓老王的進(jìn)程開機(jī)自啟動(dòng)，調(diào)了兩三天后，不定時(shí)地提示個(gè)Oops提示，小王按照“以前代碼不出現(xiàn)，新加的出現(xiàn)，那么起因絕對(duì)在新代碼內(nèi)”的慣性思維，認(rèn)為是新加的Qt導(dǎo)致的，然后小王就不斷測(cè)試，不斷查找bug中。..。..。這樣就過去了十年。

但原因其實(shí)是小王沒有open設(shè)備，即驅(qū)動(dòng)層沒有初始化定時(shí)器隊(duì)列，那么中斷處理函數(shù)中50ms觸發(fā)的隊(duì)列就為一個(gè)空值，空指針時(shí)Linux內(nèi)核當(dāng)然“哎呦”一下提醒你了，而不定時(shí)地提示其實(shí)就是因?yàn)?a target="_blank">電源不定時(shí)地松動(dòng)，gpio檢測(cè)到掉電了所以觸發(fā)了中斷。

實(shí)際上，這樣的案例十分常見，原本想A-》B-》C，實(shí)際使用是A-》D-》C，又或者驅(qū)動(dòng)中有某個(gè)變量忘記初始化等等，這時(shí)分析Oops就可以十分快速地解決問題。那接下來我們就用Linux中標(biāo)準(zhǔn)驅(qū)動(dòng)去觸發(fā)一個(gè)Oops，對(duì)的你沒看錯(cuò)，Linux內(nèi)核標(biāo)準(zhǔn)源碼也存在這樣的異常，而且我們也可以去修復(fù)這樣的問題。

使用我司的EasyARM-iMX283開發(fā)板，內(nèi)核源碼為光盤內(nèi)的Linux-2.6.35.3.tar.bz2，編譯方法請(qǐng)參考光盤資料，我們需要把lcd的背光驅(qū)動(dòng)修改為ko模式。

燒錄完新內(nèi)核，加載新編譯出來的drivers/video/backlight/mxs_bl.ko文件就會(huì)提示以下Oops信息：

乍看之下，這段信息跟亂碼差不多，但只要你一層層地分析，你就會(huì)發(fā)現(xiàn)，這些信息已經(jīng)告訴了我們錯(cuò)誤的原因。接下來就開始我們的Oops分析之旅。

1、主要錯(cuò)誤信息

用于提示錯(cuò)誤的類型，這里表示使用空指針。

2、操作入口

用于提示錯(cuò)誤的操作，這里表示加載mxs_bl模塊時(shí)出錯(cuò)，對(duì)應(yīng)于加載操作insmod mxs_bl.ko。

3、PC指針

用于提示出錯(cuò)時(shí)的PC指針位置，PC指針即當(dāng)前程序運(yùn)行點(diǎn)的地址，這里提示表示錯(cuò)誤函數(shù)為regulator_set_current_limit，偏移地址為0xc。

4、LR指針

用于提示出錯(cuò)時(shí)的LR指針位置，LR指針即調(diào)用子函數(shù)的上一個(gè)函數(shù)名以及入口偏移量，這里表示上一個(gè)函數(shù)為set_bl_intensity，偏移地址為0xd8。即set_bl_intensity調(diào)用regulator_set_current_limit時(shí)出錯(cuò)。

5、寄存器值

用于記錄出錯(cuò)時(shí)各個(gè)寄存器的值，對(duì)于匯編比較熟悉的同志們可以研究一下這段信息。

6、出錯(cuò)進(jìn)程信息

用于提示出錯(cuò)的進(jìn)程id號(hào)與進(jìn)程名稱。出錯(cuò)進(jìn)程為insmod， PID號(hào)2261，對(duì)于多任務(wù)系統(tǒng)中，可能存在多個(gè)PID調(diào)用同一個(gè)接口的情況。

7、出錯(cuò)時(shí)的堆棧信息

用于提示出錯(cuò)時(shí)堆棧內(nèi)保存的寄存器信息，當(dāng)程序由于中斷發(fā)生或子程序調(diào)用時(shí)，會(huì)執(zhí)行壓棧操作，即將運(yùn)行環(huán)境保存到堆棧內(nèi)，保證退出中斷或跳出子程序后，運(yùn)行環(huán)境不發(fā)生改變。

而此處的堆棧信息即記錄了程序運(yùn)行時(shí)的環(huán)境信息。從中我們可以找到許多LR地址，從而分析出函數(shù)調(diào)用關(guān)系，與下一段的信息有類似作用。

8、函數(shù)執(zhí)行的回溯關(guān)系

用于表示函數(shù)的調(diào)用關(guān)系，通過這段信息我們可以知道，函數(shù)的整個(gè)執(zhí)行流程，知道它的函數(shù)調(diào)用關(guān)系，最后整理出來的函數(shù)執(zhí)行流程如下：

從中我們看到了熟悉的init函數(shù)、probe函數(shù)、以及清楚probe函數(shù)下執(zhí)行的操作過程是到哪一步出錯(cuò)的?，F(xiàn)在我們知道了代碼的執(zhí)行流程，出錯(cuò)的PC指針的位置，但還是看不到代碼，出錯(cuò)指針處我們只看到了一串?dāng)?shù)字，那么接下來我們就操作一下，把pc指針的數(shù)據(jù)變?yōu)橛幸饬x的代碼。

第一步，分辨出錯(cuò)誤代碼在什么位置

這次實(shí)驗(yàn)涉及的二進(jìn)制文件有內(nèi)核的燒錄固件以及驅(qū)動(dòng)的ko文件，所以第一步分析就需要確定出錯(cuò)代碼是在內(nèi)核固件里還是ko文件里。

首先得到內(nèi)核代碼的范圍，用以下命令將內(nèi)核反匯編。

查看這個(gè)文件的格式如是：

第一列行數(shù)，第二列運(yùn)行地址，第三列二進(jìn)制碼，第四列匯編代碼，既然第二列為運(yùn)行地址，即等同于程序運(yùn)行到這行時(shí)，pc指針的值等于這個(gè)數(shù)值。這樣只要翻看這個(gè)文件的頭部以及尾部，就能知道內(nèi)核代碼的PC指針范圍為：c0008000~c0562338。

根據(jù)前面第5步寄存器值，出錯(cuò)時(shí)PC指針為c02f1878，即在內(nèi)核源碼范圍內(nèi)。

第二步，分析出錯(cuò)函數(shù)的出錯(cuò)語(yǔ)句

那么根據(jù)第3步PC指針，得到regulator_set_current_limit的匯編代碼，如下：

函數(shù)入口地址為c02f186c 《regulator_set_current_limit》。

在第3步PC指針指出偏移地址為“PC is at regulator_set_current_limit+0xc”。

PC = 0xc02f1878 = 0xc02f186c + 0xc，符合匯編代碼地址。

第三步，找到出錯(cuò)函數(shù)的C語(yǔ)言代碼

這步可以說是最困難的，因?yàn)閮?nèi)核代碼層次多，同名函數(shù)也可能存在許多份，可能幾份編譯進(jìn)內(nèi)核（static聲明的局部函數(shù)），也可能沒編譯進(jìn)內(nèi)核，如何從眾多的代碼中分析出具體哪段呢。

本人就使用了一些小手段，首先給每個(gè)同名函數(shù)的入口加段亂碼，讓編譯器篩選出編譯進(jìn)內(nèi)核的文件（因?yàn)閬y碼，所以編譯會(huì)報(bào)錯(cuò)），然后給剩下的函數(shù)加打印語(yǔ)句，通常經(jīng)過第一步之后，可選的目標(biāo)就兩三個(gè)，通過打印進(jìn)一步確認(rèn)代碼即可。

以下為篩選出來的C語(yǔ)言代碼。

看到這好像是定位了函數(shù)，但對(duì)于不熟悉匯編的人來說，C與匯編還是沒有關(guān)聯(lián)起來，好像進(jìn)入了死胡同，但先別氣餒，從上面的匯編代碼中我們知道，函數(shù)名即為函數(shù)的首地址，那么調(diào)用子函數(shù)即需要讓CPU知道子函數(shù)名，那么匯編如何調(diào)用子函數(shù)呢？使用bl指令， bl+子函數(shù)名。既然匯編有這么一個(gè)特性，那么我們看匯編代碼。

上面582734行為“bl c0493104 《mutex_lock》”這句調(diào)用了子函數(shù)，再看C中調(diào)用此函數(shù)的語(yǔ)句。

那么結(jié)果顯而易見，不可能定義個(gè)變量都報(bào)錯(cuò)吧，所以唯一可能錯(cuò)誤的語(yǔ)句就是struct regulator_dev *rdev = regulator-》rdev，同理，這句的前半部也只是定義一個(gè)rdev的變量，再結(jié)合內(nèi)核給出來的提示——空指針，所以錯(cuò)誤就是regulator-》rdev是一個(gè)空指針。

最終的問題就歸結(jié)于，為什么regulatar-》rdev為空指針。這部分的查閱代碼以及推理需要更深層次地挖掘，工作量也非本文能說清的，故作者在這里就大膽地推測(cè)與上面的A-》B-》C模型類似。所以我們就需要在這個(gè)資源存在的時(shí)刻，調(diào)用它之前給它賦值。

這時(shí)侯，我們就需要拿出第8步函數(shù)執(zhí)行的回溯關(guān)系圖，既然知道這個(gè)圖中最后的函數(shù)的輸入參數(shù)regulator的rdev為空，那么我們就關(guān)心regulator結(jié)構(gòu)體以及它的意義。從結(jié)構(gòu)體的意義我們才能知道如何給它賦值。

在相關(guān)的代碼文件中搜索關(guān)鍵字”regulator”或”regulator =”（建議搜這個(gè)，因?yàn)檫@種才是賦值語(yǔ)句）得到如下代碼。

分析這個(gè)函數(shù)可知，regulator實(shí)際是pdata的一個(gè)成員，他需要data來初始化，那么接下來的事情就簡(jiǎn)單了，在回溯關(guān)系中找一個(gè)位置把data的數(shù)據(jù)塞入pdata中，剛好這段函數(shù)就是初始化的regulator的，那就直接拿去用吧。

把這段添加到probe函數(shù)內(nèi)的這個(gè)位置，實(shí)現(xiàn)了在mxsbl_probe和mxsbl_do_probe之間賦值此變量。

這樣重新編譯后即可正常加載ko文件。