linux內核設計與實現一書閱讀整理 之第十八章

CHAPTER 18 調試

18.1 準備開始

須要的是準備是： - 一個bug - 一個藏匿bug的內核版本 - 相關內核代碼的知識和運氣

重點： 想要成功的進行調試，就取決因而否能讓這些錯誤重現。如若不能，消滅bug就只能經過抽象出問題，再從代碼中尋找蛛絲馬跡來進行了。

18.2 內核中的bug

1. bug出現時可能的症狀：

   • 錯誤代碼。（如沒把正確的值存放在恰當的位置）
   • 同步時發生的錯誤。（如共享變量鎖定不當）
   • 錯誤的管理硬件。（如給錯誤的控制寄存器發送錯誤的指令）
   • ......

2. 內核bug發做時可能的症狀：

   • 下降全部程序的運行性能
   • 毀壞數據
   • 使得系統處於死鎖狀態

   - .......

   概述：

3. 內核中的bug表現得不像用戶級程序中那麼清晰——由於內核、用戶以及硬件之間的交互會很微妙

4. 從隱藏在源代碼中的錯誤到展示在目睹者面前的bug，每每是經歷一系列連鎖反應的事件纔可能觸發的

18.3 經過打印來調試

18.3.1 健壯性

1. 健壯性是printk()函數最容易讓人們接受的一個特質，在任什麼時候候，任何地方都能調用它。

   • 在中斷上下文和進程上下文中被調用
   • 在任何持有鎖時被調用
   • 在多處理器上同時被調用，而且沒必要使用鎖。

2. printk()函數變體——early-printk()函數，區別僅在於能夠更早（甚至在啓動初期，終端尚未初始化以前）地工做

3. 彈性極佳。

18.3.2 日誌等級

• printk() 與printf()主要的的區別：前者能夠指定一個日誌級別，內核根據這個級別來判斷是否打印消息。內核把級別比某個特定值低的全部消息顯示在終端上。
• 終端默認的記錄等級是KERN_WARNING
• 內核將最重要的記錄等級KERNEMERG定爲<0>；將可有可無的記錄等級KERNDEBUG定義爲<7>
• 0 KERNEMERG 最重要 …… 7 KERNDEBUG 最不重要
• 對於調試信息， 有兩種賦予記錄等級的方法：
  • 保持終端的默認記錄等級不變，給全部調試信息KERN_CRIT或更低的等級。
  • 給全部調試信息KERN_DEBUG等級，調整終端的默認記錄等級。

18.3.3 記錄緩衝區

1. 內核消息都被記錄在環形隊列中，以隊列方式進行讀寫；大小能夠經過設置CONFIGLOGBUF_SHIFT進行調整
2. 在單處理器上，該緩衝區大小默認爲16KB，也就是說，超過的消息將覆蓋舊消息

3. 優點：

   • 讀寫同步問題容易解決
   • 記錄的維護更加方便

4. 缺點：可能會丟失信息。

18.3.4 syslogd和klogd ###

這是兩個用戶空間的守護進程，klogd從記錄緩衝區中獲取內核消息，再經過syslogd守護進程將他們保存在系統日誌文件中。 - klogd

- 既能夠從/proc/kmsg文件中，也能夠經過syslog()系統調用讀取這些消息。
- 默認是/proc方式。
- 兩種狀況klogd都會阻塞，知道有新的內核消息可供讀出，喚醒以後默認處理是將消息傳給syslogd。
- 能夠經過-c標誌來改變終端的記錄等級

• syslogd
  • 將它接收到的全部消息添加到一個文件中，默認是/var/log/messages。

18.4 oops

• • oops是內核告知用戶有不幸發生的最經常使用方式（由於內核是整個系統的管理者，不能將本身殺死，也很難自行修復）
• • 一般，發送了oops以後，內核會處於不穩定的狀態；若是oops在其餘進程（除了0號idle和1號init進程）運行的時候發生，內核會殺死這些進程並嘗試繼續執行

• 過程包括：

  • 向終端上輸出錯誤消息
  • 輸出寄存器中保存的信息
  • 輸出可供跟蹤的回溯線索

• 關於oops發生的時機：

1.發生在中斷上下文：內核沒法繼續，會陷入混亂，致使系統死機

2.發生在idle進程或init進程（0號進程和1號進程），同上

3.發生在其餘進程運行時，內核會殺死該進程並嘗試着繼續執行

• oops發生的可能緣由：

  內存訪問越界

  非法的指令

  ……

• oops中包含的重要信息：寄存器上下文和回溯線索回溯線索：顯示了致使錯誤發生的函數調用鏈。

  寄存器上下文信息也頗有用，好比幫助衝進引起問題的現場

18.4.1 ksymoops

• 將回溯線索中的地址轉換成有意義的符號名稱：

•    ksymoops saved_oops.txt

18.4.2 kallsyms

• 經過定義CONFIG_KALLSYMS配置選項啓用，該選項中存放內核鏡像中相應函數地址的符號名稱，內核能夠打印解碼好的跟蹤線索

18.5 內核調試配置選項

• 位於內核配置編輯器的內核開發菜單項中，都依賴於CONFIGDEBUGKERNEL。

  slab layer debugging slab層調試選項 high-memory debugging 高端內存調試選項 I/O mapping debugging I/O映射調試選項 spin-lock debugging 自旋鎖調試選項 stack-overflow debugging 棧溢出檢查選項 sleep-inside-spinlock checking 自旋鎖內睡眠選項 ……

- 原子操做：指那些可以不分隔執行的東西；在執行時不能中斷不然就是完不成的代碼。

例如；正在使用一個自旋鎖或禁止搶佔的代碼。
      使用鎖時睡眠是引起死鎖的元兇。

18.6 引起bug並打印信息

1. 利用BUG()以及BUG_ON（）（由於大多數體系結構都把這兩個函數定義成某種非法操做，能夠觸發oops）

   • 當作斷言或者條件語句

2. 調用panic()函數會在打印錯誤信息的同時掛起系統

   • panic("terrible thing"，terrible_thing)

3. 調用dump_stack()，只在終端上打印寄存器上下文及函數的跟蹤線索

18.7 神奇的系統請求鍵

• 這個功能能夠經過定義CONFIGMAGICSYSRQ配置選項來啓用。SysRq（系統請求）鍵在大多數鍵盤上都是標準鍵。
• 該功能被啓用時，不管內核出於什麼狀態，均可以經過特殊的組合鍵和內核進行通訊。

• 除了配置選項之外，還要經過一個sysctl用來標記該特性的開或關，啓動命令以下：

  echo 1 > /proc/sys/kernel/sysrq

• Sysrq的幾個命令：

  SysRq-s：將「髒」緩衝區跟硬盤交換分區同步
   SysRq-u：卸載全部的文件系統
   SysRq-b：重啓設備

18.8 內和調試的傳奇

18.8.1 gdb

- 啓動內核調試器

gdb vmlinux（未經壓縮的內核映像）-

• 可使用gdb的全部命令來獲取信息。例如：

  打印一個變量的值：
           p global_variable
  
       反彙編一個函數：
           disassemble function
  
          -g參數還能夠提供更多的信息。

• 侷限性：

  沒有辦法修改內核數據

  不能單步執行內核代碼

18.8.2 kgdb

• 是一個補丁 ，可讓咱們在遠程主機上經過串口利用gdb的全部功能對內核進行調試。
• 須要兩臺計算機：儀態運行帶有kgdb補丁的內核，第二胎經過串行線使用gdb對第一臺進行調試。

- 經過kgdb，gdb的全部功能都能使用:

- 讀取和修改變量值
     - 設置斷點
     - 設置關注變量
     -  單步執行

18.9 探測系統

18.9.1 使用uid做爲選擇條件

1. if(current->uid != 7777)
2. {
3. /老算法/
4. else
5. {
6. /新算法/
7. }

18.9.2 使用條件變量

• 若是代碼與進程無關，或者但願有一個針對全部狀況都能使用的機制來控制某個特性，可使用條件變量。

• 這種方式比使用UID更簡單，只須要建立一個全局變量做爲一個條件選擇開關：

  若是該變量爲0，就使用某一個分支上的代碼；
    不然，選擇另一個分支。

• 操控方式：某種接口，或者調試器。

18.9.3 使用統計量

• 這種方法經常使用於使用者須要掌握某個特定事件的發生規律的時候。
• 方法是建立統計量，並提供某種機制訪問其統計結果。

定義全局變量

在/proc目錄中建立一個文件
       or新建一個系統調用
       or經過調試器直接訪問（最直接）

18.9.4.重複頻率限制

（1）重複頻率限制 （2）發生次數限制

18.10 用二分查找法找出引起罪惡的變動

18.11 使用Git進行二分搜索

總結

本章主要講內核的調試，調試過程就是一種尋求實現與目標誤差的行爲，經過學習各類調試技巧，，發現困難重重，但相信有一天努力會有成果的。

參考資料

《linux內核設計與實現》原書第三版