中文字幕 另类精品,亚洲欧美一区二区蜜桃,日本在线精品视频免费,孩交精品乱子片免费

<sup id="3hn2b"></sup>

    1. <sub id="3hn2b"><ol id="3hn2b"></ol></sub><legend id="3hn2b"></legend>

      1. <xmp id="3hn2b"></xmp>

      2. 新聞中心

        EEPW首頁 > 嵌入式系統(tǒng) > 設計應用 > Linux編程時遇到Oops提示該如何排查?

        Linux編程時遇到Oops提示該如何排查?

        作者:ZLG致遠電子 時間:2018-11-30 來源:電子產(chǎn)品世界 收藏

          用于表示函數(shù)的調用關系,通過這段信息我們可以知道,函數(shù)的整個執(zhí)行流程,知道它的函數(shù)調用關系,最后整理出來的函數(shù)執(zhí)行流程如下:

        本文引用地址:http://www.antipu.com.cn/article/201811/395128.htm

          


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

          第一步,分辨出錯誤代碼在什么位置

          這次實驗涉及的二進制文件有內核的燒錄固件以及驅動的ko文件,所以第一步分析就需要確定出錯代碼是在內核固件里還是ko文件里。

          首先得到內核代碼的范圍,用以下命令將內核反匯編。

          


          查看這個文件的格式如是:

          


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

          根據(jù)前面第5步寄存器值,出錯時PC指針為c02f1878,即在內核源碼范圍內。

          第二步,分析出錯函數(shù)的出錯語句

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

          


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

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

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

          第三步,找到出錯函數(shù)的C語言代碼

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

          本人就使用了一些小手段,首先給每個同名函數(shù)的入口加段亂碼,讓編譯器篩選出編譯進內核的文件(因為亂碼,所以編譯會報錯),然后給剩下的函數(shù)加打印語句,通常經(jīng)過第一步之后,可選的目標就兩三個,通過打印進一步確認代碼即可。

          以下為篩選出來的C語言代碼。

          


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

          上面582734行為“bl c0493104”這句調用了子函數(shù),再看C中調用此函數(shù)的語句。

          


          那么結果顯而易見,不可能定義個變量都報錯吧,所以唯一可能錯誤的語句就是struct regulator_dev *rdev = regulator->rdev,同理,這句的前半部也只是定義一個rdev的變量,再結合內核給出來的提示——空指針,所以錯誤就是regulator->rdev是一個空指針。

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

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

          


          在相關的代碼文件中搜索關鍵字”regulator”或”regulator =”(建議搜這個,因為這種才是賦值語句)得到如下代碼。

          


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

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

          


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


        上一頁 1 2 下一頁

        關鍵詞: Linux Oops

        評論


        相關推薦

        技術專區(qū)

        關閉