YVR18資料關注點6：核心除錯手段
演講224介紹了在kselftest中增加ftracetest用例，還介紹了在核心中做GCOV的方法。這讓我想起要把Documents/dev-tools目錄看一遍的計劃，就著寫這個總結，我把相關的邏輯理一下。
Linux核心現在進展原來越快，越來越成熟，現在上傳一個特性到核心中要經過的測試原來越多了。過去我們一般會做checkpatch，做一個內部review，然後進行功能測試，LTP測試，就可以開始上傳了。
幾年不看，其實現在已經不止有這些方法了，我們分兩個維度來看：
靜態檢查的，除了checkpatch，我們還可以用sparse。用法如下（在安裝了sparse的前提下）：
make C=1
這會增加更嚴格的習慣檢查。檢查是附屬在普通編譯過程中的，如果你已經編譯了所有.o了，這個檢查不會發生。
還有一個更強大的是胭脂蟲(coccinelle)，用法如下（在安裝了coccinelle以後，注1）：
make coccicheck
這個命令可以縮小到某個目錄的範圍內，比如：
make coccicheck M=my/own/directory
我試了一下，這個檢查的功能還是很強大的，比如我的程式碼中有這麼一行：
q->svas->nr_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT
它還能報這種錯：
WARNING: Consider using vma_pages helper on vma
這個可以作為上傳前標準檢查的一部分。
動態檢查的，我們有如下工具可以用：
kselftest：這個類似LTP，是內建的一組功能測試用例，這樣編譯和執行：
make -C tools/testing/selftest make kselftest
其實編譯出來的就是一個個獨立的可執行程式，拷貝過去直接執行就可以了。
gcov：這是把gcov的功能用到核心上。在使用者態做單元測試一般會用gcov和lcov檢查覆蓋率的，這個功能現在在核心中也可以用了。它通過配置項CONFIG_GCOV_KERNEL使能。開啟後，可以在/sys/kernel/debugfs/gcov找到所有跟蹤資料檔案（*.gcda)，用gcov命令就可以直接看到程式碼的執行覆蓋率。
kmemleak和Kasan：這兩個是自動記憶體檢查，前者發現記憶體洩漏，後者發現use-after-free錯誤，分別通過CONFIG_DEBUG_KMEMLEAK和CONFIG_KASAN使能，發現有問題會自動抱錯的，可以作為基本CI系統的一部分來用。
還有一個Kcov，我在ARM64平臺跑不起來，就不討論了。
注1：我自己使用Ubuntu 18.04，這上面的coccinelle版本很舊，在最新的核心（4.19）上執行不起來，建議下原始碼自行編譯。另外注意：coccinelle的configure寫得有問題，檢查不到部分開發庫不存在，所以如果編譯失敗，就安裝一下抱錯的那個庫的開發包即可。