|
悄悄地進(jìn)入Linux內(nèi)核調(diào)試(一) 本文基址：http://blog.csdn.net/cugxueyu/archive/2007/12/21/1957740.aspx ※ 調(diào)試工作艱苦，是內(nèi)核級開發(fā)區(qū)別于用戶級開發(fā)的一個顯著特點(diǎn)。
※ 駕馭內(nèi)核調(diào)試的能力，很大程度上取決于經(jīng)驗和對整個操作系統(tǒng)的把握。
一、調(diào)試前的準(zhǔn)備
內(nèi)核級bug具有行為不可靠，定義不清晰或者說很難再現(xiàn)的諸多特定，為內(nèi)核級的bug跟蹤和調(diào)試帶來了很大的困難。
※ 對于一些定義不清楚地bug，問題的關(guān)鍵就是找到bug的源頭，很多時候，當(dāng)你精確地重現(xiàn)一個bug的時候，你就離成功不遠(yuǎn)了。
二、內(nèi)核中的bug
從隱藏在源代碼中的錯誤到展現(xiàn)在目擊者面前的bug，其發(fā)作往往是一系列連鎖反應(yīng)的事件才可能出發(fā)的。
雖然內(nèi)核調(diào)試有一定的困難，但是通過你的努力和理解，說不定你會喜歡上這樣的挑戰(zhàn)。
三、printk( )
內(nèi)核提供的格式化打印函數(shù)。
1、printk函數(shù)的健壯性
健壯性是printk最容易被接受的一個特質(zhì)，幾乎在任何地方，任何時候內(nèi)核都可以調(diào)用它（中斷上下文、進(jìn)程上下文、持有鎖時、多處理器處理時等）。
※ 在系統(tǒng)啟動過程中，終端初始化之前，在某些地方是不能調(diào)用的。
2、記錄等級
printk函數(shù)可以指定一個記錄級別，內(nèi)核根據(jù)這個級別來判斷是否在終端上打印消息。
記錄級別定義在<linux/kernel.h>中：
#define KERN_EMERG "<0>" /* system is unusable */
#define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ 調(diào)用方式：printk(KER_DEBUG “This is a debug notice!/n”);
內(nèi)核用這個指定的紀(jì)錄等級和當(dāng)前終端的紀(jì)錄等級console_loglevel比較，來決定是不是向終端打印。
關(guān)于< linux/kernel.h >的console_loglevel 定義：
#define console_loglevel (console_printk[0])
<printk.c>定義：
int console_printk[4] = {
DEFAULT_CONSOLE_LOGLEVEL, /* console_loglevel */
DEFAULT_MESSAGE_LOGLEVEL, /* default_message_loglevel */
MINIMUM_CONSOLE_LOGLEVEL, /* minimum_console_loglevel */
DEFAULT_CONSOLE_LOGLEVEL, /* default_console_loglevel */
};
3、記錄緩沖區(qū)
內(nèi)核消息都被保存在一個LOG_BUF_LEN大小的環(huán)形隊列中。
關(guān)于LOG_BUF_LEN定義：
#define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT)
※ 變量CONFIG_LOG_BUF_SHIFT在內(nèi)核編譯時由配置文件定義，對于i386平臺，其值定義如下（在linux26/arch/i386/defconfig中）：
CONFIG_LOG_BUF_SHIFT=18
記錄緩沖區(qū)操作：
①、消息被讀出到用戶空間時，此消息就會從環(huán)形隊列中刪除。
②、當(dāng)消息緩沖區(qū)滿時，如果再有printk()調(diào)用時，新消息將覆蓋隊列中的老消息。
③、在讀寫環(huán)形隊列時，同步問題很容易得到解決。
※ 這個紀(jì)錄緩沖區(qū)之所以稱為環(huán)形，是因為它的讀寫都是按照環(huán)形隊列的方式進(jìn)行操作的。
4、syslogd和klogd
在標(biāo)準(zhǔn)的Linux系統(tǒng)上，用戶空間的守護(hù)進(jìn)程klogd從紀(jì)錄緩沖區(qū)中獲取內(nèi)核消息，再通過syslogd守護(hù)進(jìn)程把這些消息保存在系統(tǒng)日志文件中。klogd進(jìn)程既可以從/proc/kmsg文件中，也可以通過syslog()系統(tǒng)調(diào)用讀取這些消息。默認(rèn)情況下，它選擇讀取/proc方式實現(xiàn)。klogd守護(hù)進(jìn)程在消息緩沖區(qū)有新的消息之前，一直處于阻塞狀態(tài)。一旦有新的內(nèi)核消息，klogd被喚醒，讀出內(nèi)核消息并進(jìn)行處理。默認(rèn)情況下，處理例程就是把內(nèi)核消息傳給syslogd守護(hù)進(jìn)程。
syslogd守護(hù)進(jìn)程一般把接收到的消息寫入/var/log/messages文件中。不過，還是可以通過/etc/syslog.conf文件來進(jìn)行配置，可以選擇其他的輸出文件。
圖1 X光了此過程：
 四、OOPS
OOPS（也稱 Panic）消息包含系統(tǒng)錯誤的細(xì)節(jié)，如 CPU 寄存器的內(nèi)容等。是內(nèi)核告知用戶有不幸發(fā)生的最常用的方式。
內(nèi)核只能發(fā)布OOPS，這個過程包括向終端上輸出錯誤消息，輸出寄存器保存的信息，并輸出可供跟蹤的回溯線索。通常，發(fā)送完OOPS之后，內(nèi)核會處于一種不穩(wěn)定的狀態(tài)。
OOPS的產(chǎn)生有很多可能原因，其中包括內(nèi)存訪問越界或非法的指令等。
※ 作為內(nèi)核的開發(fā)者，必定將會經(jīng)常處理OOPS。
※ OOPS中包含的重要信息，對所有體系結(jié)構(gòu)的機(jī)器都是完全相同的：寄存器上下文和回溯線索（回溯線索顯示了導(dǎo)致錯誤發(fā)生的函數(shù)調(diào)用鏈）。
1、ksymoops
在 Linux 中，調(diào)試系統(tǒng)崩潰的傳統(tǒng)方法是分析在發(fā)生崩潰時發(fā)送到系統(tǒng)控制臺的 Oops 消息。一旦您掌握了細(xì)節(jié)，就可以將消息發(fā)送到 ksymoops 實用程序，它將試圖將代碼轉(zhuǎn)換為指令并將堆棧值映射到內(nèi)核符號。
※ 如：回溯線索中的地址，會通過ksymoops轉(zhuǎn)化成名稱可見的函數(shù)名。
圖2X光了格式化 Oops 消息過程：
 ksymoops需要幾項內(nèi)容：Oops 消息輸出、來自正在運(yùn)行的內(nèi)核的 System.map 文件，還有 /proc/ksyms、vmlinux 和 /proc/modules。
關(guān)于如何使用 ksymoops，內(nèi)核源代碼 /usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手冊頁上有完整的說明可以參考。Ksymoops 反匯編代碼部分，指出發(fā)生錯誤的指令，并顯示一個跟蹤部分表明代碼如何被調(diào)用。
2、kallsyms
開發(fā)版2.5內(nèi)核引入了kallsyms特性，它可以通過定義CONFIG_KALLSYMS編譯選項啟用。該選項可以載入內(nèi)核鏡像所對應(yīng)的內(nèi)存地址的符號名稱（即函數(shù)名），所以內(nèi)核可以打印解碼之后的跟蹤線索。相應(yīng)，解碼OOPS也不再需要System.map和ksymoops工具了。另外，
這樣做，會使內(nèi)核變大些，因為地址對應(yīng)符號名稱必須始終駐留在內(nèi)核所在內(nèi)存上。
#cat /proc/kallsyms
c0100240 T _stext
c0100240 t run_init_process
c0100240 T stext
c0100269 t init
…
五、內(nèi)核調(diào)試配置選項
在編譯內(nèi)核的時候，為了方便調(diào)試和測試代碼，內(nèi)核提供了許多配置選項。
※ 啟用選項例如：
slab layer debugging（slab層調(diào)試選項）、high-memory debugging（高端內(nèi)存調(diào)試選項）、I/O mapping debugging（I/O映射調(diào)試選項）、spin-lock debugging（自旋鎖調(diào)試選項）、stack-overflow checking（棧溢出檢查選項）和sleep-inside-spinlock checking（自旋鎖內(nèi)睡眠選項）等。
1、調(diào)試原子操作
從內(nèi)核2.5開發(fā)，為了檢查各類由原子操作引發(fā)的問題，內(nèi)核提供了極佳的工具。
內(nèi)核提供了一個原子操作計數(shù)器，它可以配置成，一旦在原子操作過程中，進(jìn)城進(jìn)入睡眠或者做了一些可能引起睡眠的操作，就打印警告信息并提供追蹤線索。
所以，包括在使用鎖的時候調(diào)用schedule()，正使用鎖的時候以阻塞方式請求分配內(nèi)存等，各種潛在的bug都能夠被探測到。
下面這些選項可以最大限度地利用該特性：
CONFIG_PREEMPT = y
CONFIG_DEBUG_KERNEL = y
CONFIG_KLLSYMS = y
CONFIG_SPINLOCK_SLEEP = y
六、引發(fā)bug并打印信息
1、一些內(nèi)核調(diào)用可以用來方便標(biāo)記bug，提供斷言并輸出信息。最常用的兩個是BUG()和BUG_ON()。
定義在<include/asm-generic>中：
#ifndef HAVE_ARCH_BUG #define BUG() do { printk("BUG: failure at %s:%d/%s()! ", __FILE__, __LINE__, __FUNCTION__); panic("BUG!"); /* 引發(fā)更嚴(yán)重的錯誤，不但打印錯誤消息，而且整個系統(tǒng)業(yè)會掛起 */ } while (0) #endif #ifndef HAVE_ARCH_BUG_ON #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0) #endif 當(dāng)調(diào)用這兩個宏的時候，它們會引發(fā)OOPS，導(dǎo)致棧的回溯和錯誤消息的打印。
※ 可以把這兩個調(diào)用當(dāng)作斷言使用，如：BUG_ON(bad_thing);
2、dump_stack()
有些時候，只需要在終端上打印一下棧的回溯信息來幫助你調(diào)試。這時可以使用dump_stack()。這個函數(shù)只在終端上打印寄存器上下文和函數(shù)的跟蹤線索。
if (!debug_check) {
printk(KERN_DEBUG “provide some information…/n”);
dump_stack();
}
備注：大部分內(nèi)容引自《Linux內(nèi)核設(shè)計與實現(xiàn) - 第2版》
|
|
|
