內核調試的難點在于它不能像用戶態程序調試那樣打斷點，隨時暫停查看各個變量的狀態。

也不能像用戶態程序那樣崩潰后迅速的重啟，恢復初始狀態。

用戶態程序和內核交互，用戶態程序的各種狀態，錯誤等可以由內核來捕獲并顯示。

而內核是直接和硬件交互的，內核出錯之后整個系統就無法正常運行了，所以要想熟練的進行內核調試，

首先要熟悉內核已經給我們提供的工具，然后實實在在的去做一些內核功能的開發，在開發的過程中不斷熟悉內核代碼，增加內核調試的經驗。

主要內容：

• 內核調試的難點
• 內核調試的工具和方法
• 總結

內核調試的難點大致有以下幾個：

1. 重現bug困難 - 如果能夠重現一個bug, 相當于成功了一半. (特別是有些bug和硬件相關, 執行幾百萬次之后才有一次錯誤)
2. 調試風險比較大 - 稍有不慎, 即造成系統崩潰
3. 定位bug的初始版本困難 - 內核版本更新很快, 很難確定bug是在那個版本開始出現的

內核調試雖然困難, 但同時也極具挑戰性, 如果能夠解決一個困擾大家多時的內核bug, 那將會給自己帶來極大的成就感. :)

而且, 隨著內核的不斷發展, 內核調試的手段和方法也在不斷進步, 下面是書中提到的一些常用的調試手段.

輸出LOG不光是內核調試, 即使是在用戶態程序的調試中, 也是經常使用的一個調試手段.

通過在可疑的代碼周圍加上一些LOG輸出, 可以準確的了解bug發生前后的一些重要信息.

linux內核中輸出LOG的函數是 PRintk (語法和printf幾乎雷同, 唯一的區別是printk可以指定日志級別)

printk之所以好用, 就在與它隨時都可以被調用, 沒有任何限制條件.

printk的輸出日志級別如下:

輸出示例:

printk(KERN_WARNING "This is a warning!/n");printk(KERN_DEBUG "This is a debug notice!/n");

標準linux系統上, printk 輸出log之后, 由用戶空間的守護進程klogd從緩沖區中讀取內核消息, 然后再通過syslogd守護進程將它們保存在系統日志文件中.

syslogd 將接受到的所有內核消息添加到一個文件中, 該文件默認為: /var/log/dmesg (系統Centos6.4 x86_64)

PS. 上篇博客中的內核模塊的輸出LOG, 都可以在 /var/log/dmesg 中看到

oopss是個擬聲詞, 類似 "哎喲" 的意思. 它是內核通知用戶有不幸發生的最常用方式.

觸發一個oops很簡單, 其實只要在上篇博客中的那些內核模塊示例中隨便找一個, 里面加上一段給未初始化的指針賦值的代碼, 就能觸發一個oops

oops中包含錯誤發生時的一些重要信息(比如, 寄存器上下文和回溯線索), 對調試bug很有幫助!

調試內核時, 還可以開啟內核編譯參數中的各種和內核調試相關的選項, 那樣還可以給我們提供內核崩潰時的一些額外信息.

調試中有時將某些情況下標記為bug, 執行到這些情況時, 提供斷言并輸出信息.

BUG 和 BUG_ON 就是2個可以主動觸發oops的內核調用.

在不應該被執行到的地方使用 BUG 或者 BUG_ON 來捕獲.

比如:

if (bad_thing)    BUG();// 或者BUG_ON(bad_thing);

如果想要觸發更為嚴重的錯誤, 可以使用 panic() 函數

比如:

if (terrible_thing)    panic("terrible thing is %ld/n", terrible_thing);

此外, 還有dump_stack 函數可以打印寄存器上下文和回溯信息.

比如:

if (!debug_check) {    printk(KERN_DEBUG "provide some information.../n");    dump_statck();}

這個系統請求鍵之所以神奇, 在于它可以在一個快掛了的系統上輸出一些有用的信息.

這個按鍵一般就是標準鍵盤上的 [SysRq] 鍵 (就在 F12 鍵右邊, 其實就是windows中截整個屏幕的按鍵)

單獨按那個鍵相當于截屏, 按住 ALT + [SysRq] = [SysRq]的功能

啟用這個鍵的功能有2個方法:

• 開啟內核編譯選項 : CONFIG_MAGIC_SYSRQ
• 動態啟用: echo 1 > /proc/sys/kernel/sysrq

支持 SysRq 的命令如下: (注意要在控制臺界面下使用這個鍵, 比如通過 ALT+CTRL+F2 進入一個控制臺界面)

linux內核的調試器可以使用 gdb或者kgdb, 配置比較麻煩, 準備實際用調試的時候再去試試效果如何..

下面一些方法是在修改內核后, 用來試探內核反應的小技巧.

比如在內核中加入了新的特性, 為了測試特性, 可以用UID來控制內核是否執行新特性.

if (current->uid != 7777) {    /* 原先的代碼 */} else {   /* 新的特性 */}

也可以設置一些條件變量來控制內核是否執行某段代碼.

條件變量可以像上篇博客中那樣, 設置在 sys 文件系統的某個文件中. 當文件中的值變化時, 通知內核執行相應的代碼.

實現思路就是在內核中的設置一個全局變量, 比如 my_count, 當內核執行到某段代碼時, 給 my_count + 1 就行.

同時還要將 my_count 打印出來(可以用printk), 便于隨時查看它的值.

有時侯, 我們需要在內核發生錯誤時打印錯誤相關的信息, 如果這個錯誤不會導致內核崩潰, 并且這個錯誤每秒會發生幾百次甚至更多.

那么, 用printk輸出的信息會非常多, 給系統造成額外的負擔.

這時, 我們就需要想辦法控制錯誤輸出的頻率, 有2種方法:

方法1: 隔一段時間才輸出一次錯誤

static unsigned long prev_jiffy = jiffies;  /* 頻率限制 */if (time_after(jiffies, prev_jiffy + 2*HZ)) {  /* 輸出間隔至少 2HZ */    prev_jiffy = jiffies;    printk(KERN_ERR "錯誤信息..../n");}

方法2: 輸出 N 次之后, 不再輸出(N是正整數)

static unsigned long limit = 0;if (limit < 5) { /* 輸出5次錯誤信息后就不再輸出 */    limit++;    printk(KERN_ERR "錯誤信息..../n");}

在內核發生了bug之后, 如果能夠知道是bug從哪個內核版本開始出現的, 那對修正這個bug會有很大的幫助.

由于內核代碼非常龐大, 即使用二分查找法, 手工去找哪個版本開始出現bug的話, 仍然是非常耗時和繁瑣的.

好在 Git 給我們提供了一個非常有用的二分搜索機制.

git bisect start  # 開始二分搜索git bisect bad <bad_revision> # 指定一個bug出現的內核版本號git bisect good <good_revision> # 指定一個沒有bug的內核版本號, 此時git會檢測2個版本直接的隱患# 根據結果再次設置 bad 和 good 的版本號, 縮小Git檢索范圍, 直至找到可疑之處為止.

當你在調試bug時用盡了一切手段仍然無濟于事時, 可以考慮求助linux社區, 求助時注意一定要描述清楚bug的狀況.

(可以參考一下別人匯報bug的格式)

linux 內核相關的郵件列表非常多: 參見 http://vger.kernel.org/vger-lists.html

和內核開發, bug匯報相關的郵件列表參見: http://vger.kernel.org/vger-lists.html#linux-kernel (這個郵件列表非常活躍, 每天的郵件都非常多!!!)

linux內核調試必須要依靠大量的實踐來掌握, 僅僅靠上面介紹的一些技巧還遠遠不夠, 只有實實在在的去閱讀內核代碼, 實實在在的去修正一個個bug, 才算真正掌握內核, 真正了解內核.

多看看之前linux內核bug的修正案例, 也是個不錯的積累經驗的方法.

PS.

對于初學者來說, 在真機上做內核開發動輒導致機器崩潰(panic), 非常麻煩. 現在的虛擬機這么強大, 建議都在虛擬機上測試linux內核修改的效果.

我之前的關于<<Linux內核設計與實現>>筆記的博客中的代碼都是在虛擬機上運行測試的.