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寫得有問題,檢查不到部分開發庫不存在,所以如果編譯失敗,就安裝一下抱錯的那個庫的開發包即可。