概述：調(diào)試工作艱難是內(nèi)核級(jí)開發(fā)區(qū)別于用戶級(jí)開發(fā)的一個(gè)顯著特點(diǎn)

18.1準(zhǔn)備開始

內(nèi)核調(diào)試往往是一個(gè)令人撓頭不已的漫長(zhǎng)過程。幸運(yùn)的是，在這些費(fèi)勁的問題中也有不少比較簡(jiǎn)單而且容易消滅的小bug，運(yùn)氣好你可能面對(duì)的是些簡(jiǎn)單的小bug。

開始做―些調(diào)查之前，不會(huì)清楚到底面對(duì)的是什么現(xiàn)在，需要的只是： 一個(gè)bug。聽起來很可笑，但確實(shí)需要一個(gè)確定的bug。如果錯(cuò)誤總是能夠重現(xiàn)的話，那對(duì)我們會(huì)有很大的幫助（有一部分錯(cuò)誤確實(shí)如此）。然而不幸的是，大部分bug通常都不是行為可靠而且定義明確的。 一個(gè)藏匿bug的內(nèi)核版本。如果你知道這個(gè)bug最早出現(xiàn)在哪個(gè)內(nèi)核版本中那就再理想不過了。 相關(guān)內(nèi)核代碼的知識(shí)和運(yùn)氣。調(diào)試內(nèi)核其實(shí)是一個(gè)棘手的問題。不過對(duì)周圍的代碼理解得越多調(diào)試起來也就越輕松。

18.2　內(nèi)核中的bug

內(nèi)核中的bug多種多樣，它們的產(chǎn)生可以有無數(shù)的原因，同時(shí)它們的表象也變化多端

• 明白無誤的錯(cuò)誤代碼（比如，沒有把正確的值存放在恰當(dāng)?shù)奈恢?#xff09;
• 同步時(shí)發(fā)生的錯(cuò)誤（比如共享變量鎖定不當(dāng)）
• 錯(cuò)誤地管理硬件（比如，給錯(cuò)誤的控制寄存器發(fā)送錯(cuò)誤的指令）。
• 降低所有程序的運(yùn)行性能到毀壞數(shù)據(jù)再到使得系統(tǒng)處于死鎖狀態(tài)，都可能是bug發(fā)作時(shí)的癥狀。

18.3通過打印來調(diào)試

printk()：內(nèi)核的格式化打印函數(shù)

1. 健壯性

彈性極佳的函數(shù)：任何時(shí)候、任何地方都能調(diào)用它
可以在中斷上下文和進(jìn)程上下文中被調(diào)用
可以在任何持有鎖時(shí)被調(diào)用
可以在多處理器上同時(shí)被調(diào)用
除非再啟動(dòng)過程中的初期就要在終端上輸出

2. 日志等級(jí)

printk()和printf()在使用上最主要的區(qū)別就是前者可以指定一個(gè)日志級(jí)別。內(nèi)核通過這個(gè)級(jí)別來判斷是否在終端上打印消息。
內(nèi)核把級(jí)別比某個(gè)特定值低的所有消息顯示在終端上。

• 0 KERN_EMERG 最重要
• 7 KERN_DEBUG 最不重要

調(diào)試信息， 有兩種賦予記錄等級(jí)的方法：

• 保持終端的默認(rèn)記錄等級(jí)不變，給所有調(diào)試信息KERN_CRIT或更低的等級(jí)。
• 給所有調(diào)試信息KERN_DEBUG等級(jí)，調(diào)整終端的默認(rèn)記錄等級(jí)。

3. 記錄緩沖區(qū)

內(nèi)核消息保存在一個(gè)LOG_BUF_LEN大小的環(huán)形隊(duì)列中，讀寫都是按照環(huán)形隊(duì)列方式操作的。
大小是可以在編譯時(shí)通過CONFIG_LOG_BUF_SHIFT進(jìn)行調(diào)整。
在單處理器的系統(tǒng)上默認(rèn)值是16kb，即內(nèi)核在同一時(shí)間只能保存16kb的內(nèi)核消息，再多的話新消息就會(huì)覆蓋老消息。

優(yōu)點(diǎn)：

• 同步問題易解決
• 記錄維護(hù)容易
  缺點(diǎn)：

• 可能會(huì)丟失消息

  18.4、oops

  1. 概述

  oops是內(nèi)核告知用戶有不幸發(fā)生的最常用的方式。
  內(nèi)核很難自我修復(fù)，也不能將自己殺死，只能發(fā)布o(jì)ops，過程：

• 向終端上輸出錯(cuò)誤消息
• 輸出寄存器中保存的信息

• 輸出可供跟蹤的回溯線索
  通常發(fā)送完oops之后，內(nèi)核會(huì)處于一種不穩(wěn)定狀態(tài)。

寄存器上下文信息也很有用，比如幫助沖進(jìn)引發(fā)問題的現(xiàn)場(chǎng)

2. ksymoops

調(diào)用ksymoops命令：將回溯線索中的地址需要轉(zhuǎn)化成有意義的符號(hào)名稱
并且還必須提供編譯內(nèi)核時(shí)產(chǎn)生的System.map。如果用的是模塊，還需要調(diào)用一些模塊信息：kysmoop saved_oops.txt

3. kallsyms

現(xiàn)在的版本中不需要使用kysmoops這個(gè)工具，因?yàn)榭赡軙?huì)發(fā)生很多問題，新版本中引入了kallsyms，可以通過定義CONFIG_KALLSYMS配置選項(xiàng)啟用。

18.5　內(nèi)核調(diào)試配置選項(xiàng)

在編譯的時(shí)候，為了方便調(diào)試和測(cè)試內(nèi)核代碼，內(nèi)核提供了許多配置選項(xiàng)。在內(nèi)核配置編輯器的內(nèi)核開發(fā)菜單。這些選項(xiàng)中，它們都依賴于CONFIG_DEBUG_KERNEL。當(dāng)開發(fā)內(nèi)核的時(shí)候，作為一種練習(xí)，不妨打開所有這些選項(xiàng)。

有些選項(xiàng)確實(shí)有用，這些選項(xiàng)確實(shí)能完成不少調(diào)試工作。

18.6　引發(fā)bug并打印信息

一些內(nèi)核調(diào)用可以用來方便標(biāo)記bug方便標(biāo)記bug提供斷言并輸出信息。最常用的兩個(gè)是BUG()和些聲明BUG_ON()。當(dāng)被調(diào)用的時(shí)候，它們會(huì)引發(fā)oops,導(dǎo)致棧的回溯和錯(cuò)誤信息的打印。大部分體系結(jié)構(gòu)把BUG()和BUG＿ON()定義成某種會(huì)導(dǎo)致oops跟硬件的體系結(jié)構(gòu)是相關(guān)的非法操作，這樣自然會(huì)產(chǎn)生需要的oops。可以把這些調(diào)用當(dāng)做斷言使用，想要斷言某種情況不該發(fā)生。

18.7　神奇的系統(tǒng)請(qǐng)求鍵

神奇的系統(tǒng)請(qǐng)求鍵是另外一根救命稻草，該功能可以通過定義CONFIG_MAGIC_SYSRQ配置選項(xiàng)來啟用。

當(dāng)該功能被啟用的時(shí)候，無論內(nèi)核處于什么狀態(tài)，都可以通過特殊的組合鍵跟內(nèi)核進(jìn)行通信。這種功能可以讓你在面對(duì)一臺(tái)奄奄一息的系統(tǒng)時(shí)能完成一些有用的工作。除了配置選項(xiàng)以外，還要通過一個(gè)sysctl用來標(biāo)記該特性的開或關(guān)。

需要啟用它時(shí)使用如下命令:echo 1> /proc/sys/kernel/sysrq

18.8　內(nèi)核調(diào)試器的傳奇

很多內(nèi)核開發(fā)者一直以來都希望能擁有一個(gè)用于內(nèi)核的調(diào)試器.不幸的是，Linus不愿意在它的內(nèi)核源代碼樹中加入一個(gè)調(diào)試器。他認(rèn)為調(diào)試器會(huì)誤導(dǎo)開發(fā)者，從而致引入不良的修正，沒有人能對(duì)他的邏輯提出異議從真正理解代碼出發(fā)，確實(shí)更能保證修正的正確性。然而，許多內(nèi)核開發(fā)者們還是希望有一個(gè)官方發(fā)布的、用于內(nèi)核的調(diào)試器。因?yàn)檫@個(gè)要求看起來不會(huì)馬上被滿足，所以許多補(bǔ)丁應(yīng)運(yùn)而生了，它們?yōu)闃?biāo)準(zhǔn)內(nèi)核附加上了內(nèi)核調(diào)試的支持，雖然這都是―些不被官方認(rèn)可的附加補(bǔ)丁，但它們確實(shí)功能完善，十分強(qiáng)大。在我們深入這些解決方案之前，先看看標(biāo)準(zhǔn)的調(diào)試器gdb能夠給我們一些什么幫助是―個(gè)不錯(cuò)的選擇。

18.9　探測(cè)系統(tǒng)

如果對(duì)內(nèi)核調(diào)試有豐富的經(jīng)驗(yàn)的話，那么你會(huì)掌握一些訣竅來幫助你更進(jìn)一步地探測(cè)系統(tǒng)從而找到想要的答案。內(nèi)核調(diào)試很有挑戰(zhàn)性，即使是一點(diǎn)小的暗示或者技巧都能給你很大的幫助我們最好把它們聯(lián)系起來。

18.9.1　用UID作為選擇條件

假設(shè)為了加入一個(gè)激動(dòng)人心的新特性，你重寫了fork()系統(tǒng)調(diào)用。除非第一次的嘗試就完美無缺，否則系統(tǒng)調(diào)試就是―場(chǎng)噩夢(mèng)。如fork()系統(tǒng)調(diào)用不正常的話，壓根就不用指望整個(gè)系統(tǒng)還能正常工作。當(dāng)然，和任何時(shí)候一樣，希望總是存在的，一般情況下，只要保留原有的算法而把你的新算法加入到其他位置上，基本就能保證安全：可以利用把用戶id作為選擇條件來實(shí)現(xiàn)這種功能，通過這種選擇條件，可以安排到底執(zhí)行哪種算法。

18.9.2　使用條件變量

如果代碼與進(jìn)程無關(guān)，或者希望有一個(gè)針對(duì)所有情況都能使用的機(jī)制來控制某個(gè)特性，可以使用條件變量。這比使用UID還來得簡(jiǎn)單，只需要?jiǎng)?chuàng)建一個(gè)全局變量作為一個(gè)條件選擇開關(guān)。如果該變量為零，就使用一個(gè)分支上的代碼。如果它不為零，就選擇另外一個(gè)分支。可以通過某種接口提供對(duì)這個(gè)變量的操控，也可以直接通過調(diào)試器進(jìn)行操控。

18.9.3　使用統(tǒng)計(jì)量

有些時(shí)候你需要掌握某個(gè)特定事件的發(fā)生規(guī)律。有些時(shí)候需要比較多個(gè)事件并從中得出規(guī)律。通過創(chuàng)建統(tǒng)計(jì)量并提供某種機(jī)制訪問其統(tǒng)計(jì)結(jié)果，很容易就能滿足這種需求。舉個(gè)例子，假設(shè)我們希望得到foo和bar的發(fā)生頻率，那么在某個(gè)文件中，當(dāng)然最好是在定義該事件的那個(gè)文件里定義兩個(gè)全局變量。

18.9.4　重復(fù)頻率限制

18.10　用二分查找法找出引發(fā)罪惡的變更

18.11　使用Git進(jìn)行二分搜索

Git源碼管理工具提供了一個(gè)有用的二分搜索機(jī)制。如果你使用Git來控制Linux源碼樹的副本，那么Git將自動(dòng)運(yùn)行二分搜索進(jìn)程。此外，Git會(huì)在修訂版本中進(jìn)行二分搜索，這樣可以找到具體哪次提交的代碼引發(fā)了bug。很多Git相關(guān)的任務(wù)比較繁雜，但使用Git進(jìn)行二分搜索并不那么的困難。

轉(zhuǎn)載于:https://www.cnblogs.com/5320zhq/p/5339113.html

總結(jié)

以上是生活随笔為你收集整理的20135320赵瀚青LINUX第十八章读书笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。