共計 5087 個字符，預計需要花費 13 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關如何解析嵌入式 Linux Kernel 錯誤跟蹤技術，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

隨著嵌入式 Linux 系統的廣泛應用，對系統的可靠性提出了更高的要求，尤其是涉及到生命財產等重要領域，要求系統達到安全完整性等級 3 級以上[1]，故障率（每小時出現危險故障的可能性）為 10- 7 以下，相當于系統的平均故障間隔時間（MTBF）至少要達到 1141 年以上，因此提高系統可靠性已成為一項艱巨的任務。對某公司在工業領域 14 878 個控制器系統的應用調查表明，從 2004 年初到 2007 年 9 月底，隨著硬軟件的不斷改進，根據錯誤報告統計的故障率已降低到 2004 年的五分之一以下，但查找錯誤的時間卻增加到原來的 3 倍以上。

這種解決問題所需時間呈上升的趨勢固然有軟件問題，但缺乏必要的手段以輔助解決問題才是主要的原因。通過對故障的統計跟蹤發現，難以解決的軟件錯誤和從發現到解決耗時較長的軟件錯誤都集中在操作系統的核心部分，這其中又有很大比例集中在驅動程序部分 [2]。因此，錯誤跟蹤技術被看成是提高系統安全完整性等級的一個重要措施[1]，大多數現代操作系統均為發展提供了操作系統內核“崩潰轉儲”機制，即在軟件系統宕機時，將內存內容保存到磁盤[3]，或者通過網絡發送到故障服務器[3]，或者直接啟動內核調試器[4] 等，以供事后分析改進。

基于 Linux 操作系統內核的崩潰轉儲機制近年來有以下幾種：

(1) LKCD（Linux Kernel Crash Dump）機制[3];

(2) KDUMP（Linux Kernel Dump）機制[4]；

(3) KDB 機制[5]；

(4) KGDB 機制[6]。

綜合上述幾種機制可以發現, 這四種機制之間有以下三個共同點：

(1) 適用于為運算資源豐富、存儲空間充足的應用場合；

(2) 發生系統崩潰后恢復時間無嚴格要求；

(3) 主要針對較通用的硬件平臺，如 X86 平臺。

在嵌入式應用場合想要直接使用上列機制中的某一種，卻遇到以下三個難點無法解決：

(1) 存儲空間不足

嵌入式系統一般采用 Flash 作為存儲器，而 Flash 容量有限，且可能遠遠小于嵌入式系統中的內存容量。因此將全部內存內容保存到 Flash 不可行。

(2) 記錄時間要求盡量短

嵌入式系統一般有復位響應時間盡量短的要求，有的嵌入式操作系統復位重啟時間不超過 2s，而上述幾種可用于 Linux 系統的內核崩潰轉儲機制耗時均不可能在 30s 內。寫 Flash 的操作也很耗時間，實驗顯示，寫 2MB 數據到 Flash 耗時達到 400ms 之多。

(3) 要求能夠支持特定的硬件平臺

嵌入式系統的硬件多種多樣，上面提到的四種機制均是針對 X86 平臺提供了較好的支持，而對于其他體系的硬件支持均不成熟。

由于這些難點的存在，要將上述四種內核崩潰轉儲機制中的一種移植到特定的嵌入式應用平臺是十分困難的。因此，針對上述嵌入式系統的三個特點，本文介紹一種基于特定平臺的嵌入式 Linux 內核崩潰信息記錄機制 LCRT(Linux Crash Record and Trace)，為定位嵌入式 Linux 系統中軟件故障和解決軟件故障提供輔助手段。

1、Linux 內核崩潰的分析

分析 Linux 內核對于運行期間各種“陷阱”的處理可以得知，Linux 內核對于應用程序導致的錯誤可以予以監控，在應用程序發生除零、內存訪問越界、緩沖區溢出等錯誤時，Linux 內核的異常處理例程可以對這些由應用程序引起的異常情況予以處理。當應用程序產生不可恢復的錯誤時，Linux 內核可以僅僅終止產生錯誤的應用程序，其他應用程序仍然可以正常運行。

如果 Linux 內核本身或者新開發的 Linux 內核模塊存在 bug，產生了“除零”，“內存訪問越界”、“緩沖區溢出”等錯誤，同樣會由 Linux 內核的異常處理例程來處理。Linux 內核通過在異常處理程序中判斷，如果發現是“嚴重的不可恢復”的內核異常，則會導致“內核恐慌”（kernel panic），即 Linux 內核崩潰。圖 1 所示為 Linux 內核對異常情況的處理流程。 

2、LCRT 機制的設計與實現

通過對 Linux 內核代碼的分析可知，Linux 內核本身提供了一種“內核通知機制”[7-8]，并預定義了“內核事件通知鏈”，使得 Linux 內核擴展開發人員可以通過這些預定義的內核事件通知鏈在特定的內核事件發生時執行附加的處理流程。通過對 Linux 內核源代碼的研究發現，對于上文中提到的“嚴重不可恢復的內核異常”，預定義了一個通知鏈和通知點，使得在發生 Linux 內核崩潰之后，可以在 Linux 內核的 panic 函數中預定義的一個“內核崩潰通知鏈”[7]上掛接 LCRT 機制來獲得 Linux 內核崩潰現場的一些信息并記錄到非易失性存儲器中，以便分析引起 Linux 內核崩潰的原因。

2.1 設計要點

LCRT 機制的設計和實現基于如下特定的機制：

(1) 編譯器選項與內核依賴

Linux 內核及相應的驅動程序都采用 GNU[9]的開源編譯器 GCC[9]編譯，為了結合 LCRT 機制方便地提取信息和記錄信息，需要采用特定的 GCC 編譯器選項來編譯 Linux 內核和相關的驅動程序以及應用程序。用到的選項為：-mpoke-function-name[9]。使用這個選項編譯出的二進制程序中可以包含 C 語言函數名稱的信息，以方便函數調用鏈回溯時記錄信息的可讀性。

(2) Linux 內核 notify_chain 機制[8]

Linux 內核提供“通知鏈”功能，并預定義了一個內核崩潰通知鏈，在 Linux 內核的異常處理例程中判斷出系統進入“不可恢復”狀態時，會沿預定義的通知鏈順序調用注冊到相應鏈中的通知函數。

(3) 函數調用的棧布局

Linux 內核的絕大部分由 C 語言實現，而且 C 語言也多用來進行 Linux 內核開發。Linux 內核及使用 LKM 擴展而加入 Linux 內核執行環境的代碼是有規律可循的，這些代碼在執行過程中產生的棧布局和這些規律的代碼相關聯。例如，這些函數在執行函數之前會保存本函數調用后的返回地址、本函數被調用時傳遞過來的參數及調用本函數的函數所擁有的棧幀的棧底。

2.2 LCRT 機制的設計思想

LCRT 機制分為 Linux 內核模塊 [8] 部分和 Linux 用戶程序部分。內核模塊部分的設計采用了 Linux 內核模塊的模式而不是直接修改 Linux 內核。這樣的設計降低了 Linux 內核和 LCRT 機制之間的耦合度，同時滿足了 Linux 內核和 LCRT 機制獨立升級完善的便利性。用戶程序部分完成從非易失性存儲器中讀取、清除 LCRT 機制保存的信息等相關功能。

在 LCRT 機制的設計中，針對嵌入式系統的特點，其設計決策有：

(1) 將對于解決和定位問題 *** 輔助意義的函數調用關系鏈記錄下來。

(2) 為了不占用過多的存儲空間，有選擇性地將函數調用序列上的函數各自用到的棧內容保存起來，而不是保存全部內容。

(3) 將記錄的信息保存到非易失性存儲器中，這樣既達到了掉電保存的目的、又縮短了寫入時間。

LCRT 機制的設計包括以下五個方面。

(1) 設計 Linux 內核模塊、動態地加載 LCRT 機制、盡量少地修改 Linux 內核代碼。

(2)在相應、預定義的 Linux 內核通知鏈上掛接 LCRT 的通知函數。

(3) 在 LCRT 機制的通知處理函數中進行堆棧回溯得到函數調用信息。

(4) 記錄回溯到的函數調用信息和堆棧空間內容到非易失性存儲器。

(5) 開發用戶空間的工具，可以從非易失性存儲器中讀取保存的信息。

2.3 LCRT 機制的實現

LCRT 機制的實現可參照 2.2 節的設計思想，分步予以實現。限于篇幅，本文不過多涉及 Linux 內核模塊的原理和實現相關的細節，僅僅給出 LCRT 機制的內核模塊實現偽代碼。用偽代碼描述 LCRT 機制的加載函數如下:

int lcrt_init(void) { printk( Registering my__panic notifier.\n  bt_nvram_ptr=(volatile unsigned char*)ioremap_ nocache (BT_NVRAM_BASE,BT_NVRAM_LENGTH); bt_nvram_index+=sizeof(struct bt_info); *)bt_nvram_ptr,BT_NVRAM_LENGTH); notifier_chain_register(panic_notifier_list, my_ panic_block); return 0; }

LCRT 機制的通知處理函數完成函數調用關系回溯、得到函數名稱、函數棧內容等工作，限于篇幅，在這里用下面偽代碼說明：

void ll_bt_information(struct pt_regs *pr) {  變量定義等初始化工作  do { reglist=*(unsigned long *)(*myfp-8); // 從函數棧幀的頂部獲取函數開始執行時保存的寄存器信息  // 從函數的代碼區中取得函數的名稱  // 從函數的棧幀里取出函數執行函數體代碼之前保存的函數參數信息  // 從本函數的棧幀中得到調用本函數的代碼所在位置和調用本函數的函數棧幀的棧底  }while(直到函數調用鏈的鏈頭);  // 取得函數調用棧幀的內容  // 填充信息記錄的記錄頭部  // 將上面的循環中取得的信息保存到非易失性存儲器中  write_to_nvram((void *)bt_nvram_ptr, bt_record_header,sizeof(bt_info_t)); }

3、驗證評估 LCRT 機制

3.1 部署 LCRT 機制

部署 LCRT 機制，使 LCRT 機制發揮作用前需要做的相關工作有：

(1)針對目標 Linux 內核編譯 LCRT 機制的 Linux 內核模塊部分;

(2) 將 LCRT 機制的內核模塊部分載入 Linux 內核。

3.2 實驗結果

為了實驗 LCRT 機制的作用效果，構造一個會造成 Linux 內核崩潰的設備驅動模塊，記這個內核驅動模塊為 bugguy.ko, 列出如下所示的 bugguy.ko 中會引起 Linux 內核崩潰的代碼如下所示:

irqreturn_t my_timer_interrupt(int irq,void *dev_id,struct pt_regs* regs) {  確認硬件狀態并清除中斷狀態  if(ujiffies   5000) { void * ill_pointer=NULL; *(unsigned long *)ill_pointer=0; } else { ujiffies++; } return IRQ_HANDLED; }

說明：用黑體標出的代碼即為產生 bug 的代碼

從上面的代碼可以看出，這個錯誤是對空指針進行解析而造成的。在一個中斷處理函數中如果發生對空指針的解析，將會引起 Linux 內核的崩潰。在部署完成 LCRT 機制的嵌入式 linux 系統上將這個 bugguy.ko 載入 Linux 內核，使得會引起 Linux 內核崩潰的中斷處理程序得以運行，LCRT 機制可以將相關的信息保存到非易失性存儲器中，在系統復位后，通過 LCRT 機制的用戶空間工具，可以將保存的信息讀取出來。實驗結果顯示，可以得到如圖 2 所示的函數調用鏈信息。

圖 2 標注即為會引起 Linux 內核崩潰的錯誤代碼的中斷處理函數即真正引起系統宕機的“罪魁禍首”。而記錄下的所有信息僅僅占用了不到 1KB 的存儲空間，寫入非易失性存儲器所耗用的時間控制在 50ms 以內。在使用少量空間和少量時間的情況下，所記錄下的信息對于查找問題和解決問題都有較大的幫助。

實驗結果表明，在 LCRT 機制的作用下，可以快速地定位到嵌入式 Linux 系統中隱藏的可能會導致系統宕機的軟件缺陷。這就為后續的故障解決和軟件完善提供了關鍵的輔助信息。對嵌入式 Linux 內核而言，即是為提高 Linux 內核的穩定性和可靠性提供了幫助。

在基于 ARM 的嵌入式 Linux 應用中，開發 LCRT 機制來記錄系統內核發生崩潰時引起崩潰的函數調用鏈和棧信息到非易失性存儲器中，截至目前為止，LCRT 機制可以記錄基于 ARM 的嵌入式 Linux 內核發生崩潰時的函數調用鏈信息，可直接得到函數名稱、函數調用鏈中單個函數被調用時的參數信息以及函數調用鏈中的函數各自的棧幀信息。這些記錄下來的信息對于完善和發展基于 ARM 的嵌入式 Linux 應用具有重要的輔助意義。

關于如何解析嵌入式 Linux Kernel 錯誤跟蹤技術就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。