Linux 內核測試和調試（4）

自動測試工具

這裏列出一些能知足不一樣需求的測試工具供你選擇。本小節只是簡單介紹個大概，並不提供詳細操做指南。

AuToTest

AuToTest 是一個全自動測試框架，存在的主要目的就是測試 Linux 內核，固然也能夠用來測試其餘東西，好比測試一塊新硬件是否能穩定工做。AuToTest 是開源軟件，以 GPL 方式受權，運行於 server-client 架構（即 C/S 架構）。你能夠經過配置 server 端來對運行了 client 端的系統執行初始化、運行與監測工做，也能夠本身在目標系統上讓 client 運行起來。另外你能夠爲這個測試框架添加測試用例，詳情請參考AuToTest 白皮書。

Linaro Automated Validation Architecture

LAVA 自動測試框架用於自動安裝於運行測試。舉個例子：你在 LAVA 裏面只需運行幾個命令就能夠跑 LTP（LCTT：Linux Test Project，中文是 Linux 測試計劃，SGI發起並由IBM負責維護，目的是爲開源社區提供測試套件來驗證Linux的可靠性、健壯性和穩定性）。經過 LAVA 命令能夠自動爲你安裝 LTP 所須要的全部依賴包，下載源碼、編譯編碼、將 LTP 安裝到某個獨立的地方，方便卸載 LTP 時能移除全部二進制文件。安裝好 LTP 後，運行 LAVA 命令時添加 'ltp' 選項就能夠運行 LTP 測試任務了，它會將測試結果以文件方式保存下來，文件名包含測試名稱、時間戳。這些測試結果能夠留着供之後參考。這是個發現軟件退化（若是軟件退化了的 話）的好方法。下面列出 LAVA 配合 LTP 使用的一些命令：

顯示 LAVA 支持的測試列表：

lava-test list-tests

安裝測試套件：

lava-test install ltp

運行測試：

lava-test run ltp

查看結果：

lava-test results show ltp-timestamp.0

卸載測試套件：

lava-test uninstall ltp

內核調試功能

Linux 內核自己包含不少調試功能，好比 kmemcheck 和 kmemleak。

kmemcheck

kmemcheck 是一個動態檢查工具，能夠檢測出一些未被初始化的內存（LCTT：內核態使用這些內存可能會形成系統崩潰）併發出警告。它的功能與 Valgrind 相似，只是 Valgrind 運行在用戶態，而 kmemchecke 運行在內核態。編譯內核時加上 CONFIG_KMEMCHECK 選項打開 kmemcheck 調試功能。你能夠閱讀 Documentation/kmemcheck.txt 來學習如何配置使用這個功能，以及如何看懂調試結果。

kmemleak

kmemleak 經過相似於垃圾收集器的功能來檢測內核是否有內存泄漏問題。而 kmemleak 與垃圾收集器的不一樣之處在於前者不會釋放孤兒目標（LCTT：不會再被使用的、應該被釋放而沒被釋放的內存區域），而是將它們打印到 /sys/kernel/debug/kmemleak 文件中。用戶態的 Valgrind 也有一個相似的功能，使用 --leak-check 選項能夠檢測並報錯內存泄漏問題，但並不釋放這個孤兒內存。編譯內核時使用 CONFIG_DEBUG_KMEMLEAK 選項打開 kmemcleak 調試功能。閱讀 Documentation/kmemleak.txt 來學習怎麼使用這個工具並讀懂調試結果。

內核調試接口

Linux 內核經過配置選項、調試用的 API、接口和框架來支持動態或靜態的調試。咱們如今就好好學習學習這些牛逼的功能，從靜態編譯選項開始講。

調試配置選項：靜態編譯

大部分 Linux 內核以及內核模塊都包含調試選項，你只要在編譯內核或內核模塊的時候添加這個靜態調試選項，程序運行時後就會產生調試信息，並記錄在 dmesg 緩存中。

調試的 API

調試 API 的一個很好的例子是 DMA-debug，用來調試驅動是否錯誤使用了 DMA 提供的 API。它會跟蹤每一個設備的映射關係，檢測程序有沒有試圖爲一些根本不存在的映射執行「取消映射」操做，檢測代碼創建 DMA 映射後可能產生的「映射丟失」的錯誤。內核配置選項 CONFIG_HAVE_DMA_APT_DEBUG 和 CONFIG_DMA_API_DEBUG 能夠爲內核提供這個功能。其中，CONFIG_DMA_API_DEBUG 選項啓用後，內核調用 DMA 的 API 的同時也會調用 Debug-dma 接口。舉例來講，當一個驅動調用 dma_map_page() 函數來映射一個 DMA 緩存時，dma_map_page() 會調用debug_dma_map_page() 函數來跟蹤這個緩存，直到驅動調用 dma_unmap_page() 來取消映射。詳細內容請參考使用 DMA 調試 API 檢測潛在的數據污染和內存泄漏問題。

動態調試

動態調試功能就是你能夠決定在程序運行過程當中是否要 pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() 這些函數正常運行起來。什麼意思？當程序運行過程當中出現錯誤時，你能夠指定程序打印有針對性的、詳細的調試信息。這功能牛逼極了，咱們再也不須要爲了添加調 試代碼定位一個問題，而從新編譯安裝內核。你能夠指定 CONDIF_DYNAMIC_DEBUG 選項打開動態調試功能，而後經過 /sys/kernel/debug/dynamic_debug/control 接口指定要打印哪些調試日誌。下面分別列出代碼級別和模塊級別打印日誌的操做方法：

讓 kernel/power/suspend.c 源碼第340行的 pr_debug() 函數打印日誌：

echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control

讓內核模塊在加載過程當中打開動態調試功能：

使用 modprobe 命令加在模塊時加上 dyndbg='plmft' 選項。

讓內核模塊的動態調試功能在重啓後依然有效：

編輯 /etc/modprobe.d/modname.conf 文件（沒有這個文件就建立一個），添加 dyndbg='plmft' 選項。然而對於哪些經過 initramfs 加載的驅動來講，這個配置基本無效（LCTT：免費奉送點比較高級的知識哈。系統啓動時，須要先讓 initramfs 掛載一個虛擬的文件系統，而後再掛載啓動盤上的真實文件系統。這個虛擬文件系統裏面的文件是 initramfs 本身提供的，也就是說你在真實的文件系統下面配置了 /etc/modprobe.d/modname.conf 這個文件，initramfs 是壓根不去理會的。站在內核驅動的角度看：若是內核驅動在 initramfs 過程當中被加載到內核，這個驅動讀取到的 /etc/modprobe.d/modname.conf 是 initramfs 提供的，而不是你編輯的那個。因此會有上述「寫了配置文件後重啓依然無效」的結論）。對於這種刁民，呃，刁驅動，咱們須要修改 grub 配置文件，在 kernel 那一行添加 module.dyndbg='plmft' 參數，這樣你的驅動就能夠開機啓動動態調試功能了。

想打印更詳細的調試信息，可使用 dynamic_debug.verbose=1 選項。參考 Documentation/dynamic-debug-howto.txt 文件獲取更多信息。

設置追蹤點

到目前爲止，咱們介紹了多種動態和靜態調試方法。靜態調試選項和靜態調試鉤子函數（好比 DMA Debug API）須要的編譯過程打開或關閉，致使了一個難過的事實：須要從新編譯安裝內核。而動態編譯功能省去了「從新編譯」這件麻煩事，可是也有不足的地方，就 是調試代碼引入了條件變量，用於判斷是否打印調試信息。這種方法可讓你在程序運行時決定是否打印日誌，但須要執行額外的判斷過程。「追蹤點」代碼只會在 程序運行過程當中使用「追蹤點」功能纔會被觸發。也就是說，「追蹤點」代碼與上述說的兩種方法都不同。當用不到它時，它不會運行（LCTT：動態調試的 話，代碼每次都須要查看下變量，而後判斷是否須要打印日誌；而「追蹤點」貌似利用某種觸發機制，不須要每次都去查看變量）。當你須要用到它時，程序的代碼 會把「追蹤點」代碼包含進去。它不會添加任何條件變量來增長系統的運行負擔。

詳細信息請參考佈置追蹤代碼的小技巧。

「追蹤點」的原理

追蹤點使用「跳躍標籤」，這是一種使用分支跳轉的編碼修正（code modification）技術。

當關閉追蹤點的時候，其僞代碼看起來時這樣的：

[ code1 ]nopback:[ code2 ]return;tracepoint:[ tracepoint code ]jmp back;

當打開追蹤點的時候，其僞代碼看起來時這樣的：（注意追蹤點代碼出現的位置）

[ code1 ]jmp tracepointback:[ code2 ]return;tracepoint:[ tracepoint code ]jmp back;

（LCTT：咳咳，解釋解釋上面兩段僞代碼吧，能看懂的大神請忽略這段註釋。不使用追蹤點時，代碼運行過程 是：code1->code2->return結束；使用追蹤點時，代碼運行過程是：code1->跳到tracepoint code執行調試代碼->跳回code2->return結束。兩段代碼的惟一區別就是第二行，前者爲 nop（不作任何操做），後者爲 jmp tracepoint （跳到調試代碼）。）

Linux 電源管理子系統的測試

使用靜態調試、動態調試和追蹤調試技術，咱們來跑一下磁盤的電源管理測試。當系統被掛起時，內核會爲磁盤建立一個休眠鏡像，使磁盤進入休眠模式，當系統從新被喚醒時，內核又利用這個休眠鏡像從新喚醒磁盤。

設置掛起設備與喚醒設備須要的時間：

echo 1 > /sys/power/pm_print_times

以 reboot 模式掛起磁盤：

echo reboot > /sys/power/diskecho disk > /sys/power/state

以 shutdown 模式掛起磁盤 —— 與 reboot 模式同樣，只是從新喚醒磁盤的話還須要電源提供。

echo shutdown > /sys/power/diskecho disk > /sys/power/state

以 platform 模式掛起磁盤 —— 能測試更多內容，好比 BIOS 掛起和喚醒，會涉及到 ACPI 功能。咱們推薦你使用這種方式，把 BIOS 也拉下水陪你玩掛起和喚醒遊戲。

echo platform > /sys/power/diskecho disk > /sys/power/state

---

via:http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3

譯者：bazz2 校對：校對者ID

本文由 LCTT 原創翻譯，Linux中國 榮譽推出

 

來源： linuxjournal

    原文： http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3        

        譯者： bazz2

               

轉載本文請遵循原文要求