Linux 內核調試器內幕

KDB 入門指南

Hariprasad Nellitheertha (nharipra@in.ibm.com), 軟件工程師, IBM

簡介：?調試內核問題時，能夠跟蹤內核執行情況并查看其內存和數據結構是非常有用的。Linux 中的內置內核調試器 KDB 提供了這種功能。在本文中您將了解如何使用 KDB 所提供的功能，以及如何在 Linux 機器上安裝和設置 KDB。您還將熟悉 KDB 中可以使用的命令以及設置和顯示選項。

Linux 內核調試器（KDB）允許您調試 Linux 內核。這個恰如其名的工具實質上是內核代碼的補丁，它允許高手訪問內核內存和數據結構。KDB 的主要優點之一就是它不需要用另一臺機器進行調試：您可以調試正在運行的內核。

設置一臺用于 KDB 的機器需要花費一些工作，因為需要給內核打補丁并進行重新編譯。KDB 的用戶應當熟悉 Linux 內核的編譯（在一定程度上還要熟悉內核內部機理），但是如果您需要編譯內核方面的幫助，請參閱本文結尾處的參考資料一節。

在本文中，我們將從有關下載 KDB 補丁、打補丁、（重新）編譯內核以及啟動 KDB 方面的信息著手。然后我們將了解 KDB 命令并研究一些較常用的命令。最后，我們將研究一下有關設置和顯示選項方面的一些詳細信息。

入門

KDB 項目是由 Silicon Graphics 維護的（請參閱參考資料以獲取鏈接），您需要從它的 FTP 站點下載與內核版本有關的補丁。（在編寫本文時）可用的最新 KDB 版本是 4.2。您將需要下載并應用兩個補丁。一個是“公共的”補丁，包含了對通用內核代碼的更改，另一個是特定于體系結構的補丁。補丁可作為 bz2 文件獲取。例如，在運行 2.4.20 內核的 x86 機器上，您會需要 kdb-v4.2-2.4.20-common-1.bz2 和 kdb-v4.2-2.4.20-i386-1.bz2。

這里所提供的所有示例都是針對 i386 體系結構和 2.4.20 內核的。您將需要根據您的機器和內核版本進行適當的更改。您還需要擁有 root 許可權以執行這些操作。

將文件復制到 /usr/src/linux 目錄中并從用 bzip2 壓縮的文件解壓縮補丁文件：

#bzip2 -d kdb-v4.2-2.4.20-common-1.bz2#bzip2 -d kdb-v4.2-2.4.20-i386-1.bz2

您將獲得 kdb-v4.2-2.4.20-common-1 和 kdb-v4.2-2.4-i386-1 文件。

現在，應用這些補丁：

#patch -p1 <kdb-v4.2-2.4.20-common-1#patch -p1 <kdb-v4.2-2.4.20-i386-1

這些補丁應該干凈利落地加以應用。查找任何以 .rej 結尾的文件。這個擴展名表明這些是失敗的補丁。如果內核樹沒問題，那么補丁的應用就不會有任何問題。

接下來，需要構建內核以支持 KDB。第一步是設置 CONFIG_KDB 選項。使用您喜歡的配置機制（xconfig 和 menuconfig 等）來完成這一步。轉到結尾處的“Kernel hacking”部分并選擇“Built-in Kernel Debugger support”選項。

您還可以根據自己的偏好選擇其它兩個選項。選擇“Compile the kernel with frame pointers”選項（如果有的話）則設置 CONFIG_FRAME_POINTER 標志。這將產生更好的堆棧回溯，因為幀指針寄存器被用作幀指針而不是通用寄存器。您還可以選擇“KDB off by default”選項。這將設置CONFIG_KDB_OFF 標志，并且在缺省情況下將關閉 KDB。我們將在后面一節中對此進行詳細介紹。

保存配置，然后退出。重新編譯內核。建議在構建內核之前執行“make clean”。用常用方式安裝內核并引導它。

回頁首

初始化并設置環境變量

您可以定義將在 KDB 初始化期間執行的 KDB 命令。需要在純文本文件 kdb_cmds 中定義這些命令，該文件位于 Linux 源代碼樹（當然是在打了補丁之后）的 KDB 目錄中。該文件還可以用來定義設置顯示和打印選項的環境變量。文件開頭的注釋提供了編輯文件方面的幫助。使用這個文件的缺點是，在您更改了文件之后需要重新構建并重新安裝內核。

回頁首

激活 KDB

如果編譯期間沒有選中 CONFIG_KDB_OFF ，那么在缺省情況下 KDB 是活動的。否則，您需要顯式地激活它－通過在引導期間將kdb=on 標志傳遞給內核或者通過在掛裝了 /proc 之后執行該工作：

#echo "1" >/proc/sys/kernel/kdb

倒過來執行上述步驟則會取消激活 KDB。也就是說，如果缺省情況下 KDB 是打開的，那么將 kdb=off 標志傳遞給內核或者執行下面這個操作將會取消激活 KDB：

#echo "0" >/proc/sys/kernel/kdb

在引導期間還可以將另一個標志傳遞給內核。 kdb=early 標志將導致在引導過程的初始階段就把控制權傳遞給 KDB。如果您需要在引導過程初始階段進行調試，那么這將有所幫助。

調用 KDB 的方式有很多。如果 KDB 處于打開狀態，那么只要內核中有緊急情況就自動調用它。按下鍵盤上的 PAUSE 鍵將手工調用 KDB。調用 KDB 的另一種方式是通過串行控制臺。當然，要做到這一點，需要設置串行控制臺（請參閱參考資料以獲取這方面的幫助）并且需要一個從串行控制臺進行讀取的程序。按鍵序列 Ctrl-A 將從串行控制臺調用 KDB。

回頁首

KDB 命令

KDB 是一個功能非常強大的工具，它允許進行幾個操作，比如內存和寄存器修改、應用斷點和堆棧跟蹤。根據這些，可以將 KDB 命令分成幾個類別。下面是有關每一類中最常用命令的詳細信息。

內存顯示和修改

這一類別中最常用的命令是 md 、 mdr 、 mm 和 mmW 。

md 命令以一個地址／符號和行計數為參數，顯示從該地址開始的 line-count 行的內存。如果沒有指定line-count ，那么就使用環境變量所指定的缺省值。如果沒有指定地址，那么 md 就從上一次打印的地址繼續。地址打印在開頭，字符轉換打印在結尾。

mdr 命令帶有地址／符號以及字節計數，顯示從指定的地址開始的 byte-count 字節數的初始內存內容。它本質上和md 一樣，但是它不顯示起始地址并且不在結尾顯示字符轉換。 mdr 命令較少使用。

mm 命令修改內存內容。它以地址／符號和新內容作為參數，用 new-contents 替換地址處的內容。

mmW 命令更改從地址開始的 W 個字節。請注意， mm 更改一個機器字。

示例

顯示從 0xc000000 開始的 15 行內存：

[0]kdb> md 0xc000000 15

將內存位置為 0xc000000 上的內容更改為 0x10：

[0]kdb> mm 0xc000000 0x10

寄存器顯示和修改

這一類別中的命令有 rd 、 rm 和 ef 。

rd 命令（不帶任何參數）顯示處理器寄存器的內容。它可以有選擇地帶三個參數。如果傳遞了 c 參數，則 rd 顯示處理器的控制寄存器；如果帶有 d 參數，那么它就顯示調試寄存器；如果帶有 u 參數，則顯示上一次進入內核的當前任務的寄存器組。

rm 命令修改寄存器的內容。它以寄存器名稱和 new-contents 作為參數，用 new-contents 修改寄存器。寄存器名稱與特定的體系結構有關。目前，不能修改控制寄存器。

ef 命令以一個地址作為參數，它顯示指定地址處的異常幀。

示例

顯示通用寄存器組：

[0]kdb> rd

[0]kdb> rm %ebx 0x25

斷點

常用的斷點命令有 bp 、 bc 、 bd 、 be 和bl 。

bp 命令以一個地址／符號作為參數，它在地址處應用斷點。當遇到該斷點時則停止執行并將控制權交予 KDB。該命令有幾個有用的變體。 bpa 命令對 SMP 系統中的所有處理器應用斷點。 bph 命令強制在支持硬件寄存器的系統上使用它。 bpha 命令類似于bpa 命令，差別在于它強制使用硬件寄存器。

bd 命令禁用特殊斷點。它接收斷點號作為參數。該命令不是從斷點表中除去斷點，而只是禁用它。斷點號從 0 開始，根據可用性順序分配給斷點。

be 命令啟用斷點。該命令的參數也是斷點號。

bl 命令列出當前的斷點集。它包含了啟用的和禁用的斷點。

bc 命令從斷點表中除去斷點。它以具體的斷點號或 * 作為參數，在后一種情況下它將除去所有斷點。

示例

對函數 sys_write() 設置斷點：

[0]kdb> bp sys_write

列出斷點表中的所有斷點：

[0]kdb> bl

清除斷點號 1：

[0]kdb> bc 1

>堆棧跟蹤

主要的堆棧跟蹤命令有 bt 、 btp 、 btc 和 bta 。

bt 命令設法提供有關當前線程的堆棧的信息。它可以有選擇地將堆棧幀地址作為參數。如果沒有提供地址，那么它采用當前寄存器來回溯堆棧。否則，它假定所提供的地址是有效的堆棧幀起始地址并設法進行回溯。如果內核編譯期間設置了CONFIG_FRAME_POINTER 選項，那么就用幀指針寄存器來維護堆棧，從而就可以正確地執行堆棧回溯。如果沒有設置 CONFIG_FRAME_POINTER ，那么 bt 命令可能會產生錯誤的結果。

btp 命令將進程標識作為參數，并對這個特定進程進行堆棧回溯。

btc 命令對每個活動 CPU 上正在運行的進程執行堆棧回溯。它從第一個活動 CPU 開始執行 bt ，然后切換到下一個活動 CPU，以此類推。

bta 命令對處于某種特定狀態的所有進程執行回溯。若不帶任何參數，它就對所有進程執行回溯。可以有選擇地將各種參數傳遞給該命令。將根據參數處理處于特定狀態的進程。選項以及相應的狀態如下：

D：不可中斷狀態
R：正運行
S：可中斷休眠
T：已跟蹤或已停止
Z：僵死
U：不可運行

這類命令中的每一個都會打印出一大堆信息。請查閱下面的參考資料以獲取這些字段的詳細文檔。

示例

跟蹤當前活動線程的堆棧：

[0]kdb> bt

跟蹤標識為 575 的進程的堆棧：

[0]kdb> btp 575

其它命令

下面是在內核調試過程中非常有用的其它幾個 KDB 命令。

id 命令以一個地址／符號作為參數，它對從該地址開始的指令進行反匯編。環境變量 IDCOUNT 確定要顯示多少行輸出。

ss 命令單步執行指令然后將控制返回給 KDB。該指令的一個變體是 ssb ，它執行從當前指令指針地址開始的指令（在屏幕上打印指令），直到它遇到將引起分支轉移的指令為止。分支轉移指令的典型示例有call 、 return 和 jump 。

go 命令讓系統繼續正常執行。一直執行到遇到斷點為止（如果已應用了一個斷點的話）。

reboot 命令立刻重新引導系統。它并沒有徹底關閉系統，因此結果是不可預測的。

ll 命令以地址、偏移量和另一個 KDB 命令作為參數。它對鏈表中的每個元素反復執行作為參數的這個命令。所執行的命令以列表中當前元素的地址作為參數。

示例

反匯編從例程 schedule 開始的指令。所顯示的行數取決于環境變量 IDCOUNT ：

[0]kdb> id schedule

執行指令直到它遇到分支轉移條件（在本例中為指令 jne ）為止：

 
[0]kdb> ssb0xc0105355  default_idle+0x25:  cli0xc0105356  default_idle+0x26:  mov  0x14(%edx),%eax0xc0105359  default_idle+0x29:  test %eax, %eax0xc010535b  default_idle+0x2b:  jne  0xc0105361 default_idle+0x31

回頁首

技巧和訣竅

調試一個問題涉及到：使用調試器（或任何其它工具）找到問題的根源以及使用源代碼來跟蹤導致問題的根源。單單使用源代碼來確定問題是極其困難的，只有老練的內核黑客才有可能做得到。相反，大多數的新手往往要過多地依靠調試器來修正錯誤。這種方法可能會產生不正確的問題解決方案。我們擔心的是這種方法只會修正表面癥狀而不能解決真正的問題。此類錯誤的典型示例是添加錯誤處理代碼以處理 NULL 指針或錯誤的引用，卻沒有查出無效引用的真正原因。

結合研究代碼和使用調試工具這兩種方法是識別和修正問題的最佳方案。

調試器的主要用途是找到錯誤的位置、確認癥狀（在某些情況下還有起因）、確定變量的值，以及確定程序是如何出現這種情況的（即，建立調用堆棧）。有經驗的黑客會知道對于某種特定的問題應使用哪一個調試器，并且能迅速地根據調試獲取必要的信息，然后繼續分析代碼以識別起因。

因此，這里為您介紹了一些技巧，以便您能使用 KDB 快速地取得上述結果。當然，要記住，調試的速度和精確度來自經驗、實踐和良好的系統知識（硬件和內核內部機理等）。

技巧 #1

在 KDB 中，在提示處輸入地址將返回與之最為匹配的符號。這在堆棧分析以及確定全局數據的地址／值和函數地址方面極其有用。同樣，輸入符號名則返回其虛擬地址。

示例

表明函數 sys_read 從地址 0xc013db4c 開始：

[0]kdb> 0xc013db4c0xc013db4c = 0xc013db4c (sys_read)

同樣，

同樣，表明 sys_write 位于地址 0xc013dcc8：

[0]kdb> sys_writesys_write = 0xc013dcc8 (sys_write)

這些有助于在分析堆棧時找到全局數據和函數地址。

技巧 #2

在編譯帶 KDB 的內核時，只要 CONFIG_FRAME_POINTER 選項出現就使用該選項。為此，需要在配置內核時選擇“Kernel hacking”部分下面的“Compile the kernel with frame pointers”選項。這確保了幀指針寄存器將被用作幀指針，從而產生正確的回溯。實際上，您可以手工轉儲幀指針寄存器的內容并跟蹤整個堆棧。例如，在 i386 機器上，%ebp 寄存器可以用來回溯整個堆棧。

例如，在函數 rmqueue() 上執行第一個指令后，堆棧看上去類似于下面這樣：

[0]kdb> md %ebp0xc74c9f38 c74c9f60  c0136c40 000001f0 000000000xc74c9f48 08053328 c0425238 c04253a8 000000000xc74c9f58 000001f0  00000246 c74c9f6c c0136a250xc74c9f68 c74c8000  c74c9f74  c0136d6d c74c9fbc0xc74c9f78 c014fe45  c74c8000  00000000 08053328[0]kdb> 0xc0136c400xc0136c40 = 0xc0136c40 (__alloc_pages +0x44)[0]kdb> 0xc0136a250xc0136a25 = 0xc0136a25 (_alloc_pages +0x19)[0]kdb> 0xc0136d6d0xc0136d6d = 0xc0136d6d (__get_free_pages +0xd)

我們可以看到 rmqueue() 被 __alloc_pages 調用，后者接下來又被 _alloc_pages 調用，以此類推。

每一幀的第一個雙字（double word）指向下一幀，這后面緊跟著調用函數的地址。因此，跟蹤堆棧就變成一件輕松的工作了。

技巧 #3

go 命令可以有選擇地以一個地址作為參數。如果您想在某個特定地址處繼續執行，則可以提供該地址作為參數。另一個辦法是使用 rm 命令修改指令指針寄存器，然后只要輸入 go 。如果您想跳過似乎會引起問題的某個特定指令或一組指令，這就會很有用。但是，請注意，該指令使用不慎會造成嚴重的問題，系統可能會嚴重崩潰。

技巧 #4

您可以利用一個名為 defcmd 的有用命令來定義自己的命令集。例如，每當遇到斷點時，您可能希望能同時檢查某個特殊變量、檢查某些寄存器的內容并轉儲堆棧。通常，您必須要輸入一系列命令，以便能同時執行所有這些工作。defcmd 允許您定義自己的命令，該命令可以包含一個或多個預定義的 KDB 命令。然后只需要用一個命令就可以完成所有這三項工作。其語法如下：

 
[0]kdb> defcmd name "usage" "help"[0]kdb> [defcmd] type the commands here[0]kdb> [defcmd] endefcmd

例如，可以定義一個（簡單的）新命令 hari ，它顯示從地址 0xc000000 開始的一行內存、顯示寄存器的內容并轉儲堆棧：

[0]kdb> defcmd hari "" "no arguments needed"[0]kdb> [defcmd] md 0xc000000 1[0]kdb> [defcmd] rd[0]kdb> [defcmd] md %ebp 1[0]kdb> [defcmd] endefcmd

該命令的輸出會是：

[0]kdb> hari[hari]kdb> md 0xc000000 10xc000000 00000001 f000e816 f000e2c3 f000e816[hari]kdb> rdeax = 0x00000000 ebx = 0xc0105330 ecx = 0xc0466000 edx = 0xc0466000.......[hari]kdb> md %ebp 10xc0467fbc c0467fd0 c01053d2 00000002 000a0200[0]kdb>

技巧 #5

可以使用 bph 和 bpha 命令（假如體系結構支持使用硬件寄存器）來應用讀寫斷點。這意味著每當從某個特定地址讀取數據或將數據寫入該地址時，我們都可以對此進行控制。當調試數據／內存毀壞問題時這可能會極其方便，在這種情況中您可以用它來識別毀壞的代碼／進程。

示例

每當將四個字節寫入地址 0xc0204060 時就進入內核調試器：

[0]kdb> bph 0xc0204060 dataw 4

在讀取從 0xc000000 開始的至少兩個字節的數據時進入內核調試器：

[0]kdb> bph 0xc000000 datar 2

回頁首

結束語

對于執行內核調試，KDB 是一個方便的且功能強大的工具。它提供了各種選項，并且使我們能夠分析內存內容和數據結構。最妙的是，它不需要用另一臺機器來執行調試。

參考資料

您可以參閱本文在 developerWorks 全球站點上的英文原文.
請在 Documentation/kdb 目錄中查找 KDB 手冊頁。
有關設置串行控制臺的信息，請查找 Documentation 目錄中的 serial-console.txt。
請在 SGI 的內核調試器項目網站上下載 KDB。
有關幾個基于方案的 Linux 調試技術的概述，請閱讀“ 掌握 Linux 調試技術”（ developerWorks，2002 年 8 月）。
教程“ 編譯 Linux 內核”（ developerWorks，2000 年 8 月）讓您完整地了解配置、編譯和安裝內核的過程。
IBM AIX 用戶可以在 KDB Kernel Debugger and Command頁面上獲取有關用于 AIX 的 KDB 的使用幫助。
那些尋求有關調試 OS/2 信息的讀者應該閱讀 IBM 紅皮書 The OS/2 Debugging Handbook（共四卷）的第 II 卷。
在 developerWorksLinux 專區中查找更多針對 Linux 開發人員的參考資料。

關于作者

Hariprasad Nellitheertha 在印度班加羅爾（Bangalore）的 IBM Linux 技術中心工作。他目前正在 Linux Change Team 從事修正內核和其它 Linux 錯誤的工作。Hari 研究過 OS/2 內核和文件系統。他的興趣包括 Linux 內核內部機理、文件系統和自主計算。可以通過nharipra@in.ibm.com與 Hari 聯系。

嵌入式操作系統的調試

熊競 (jxiong@ict.ac.cn)中科院計算所

簡介：?調試是開發過程中必不可少的環節，通用的桌面操作系統與嵌入式操作系統在調試環境上存在明顯的差別。前者，調試器與被調試的程序往往是運行在同一臺機器、相同的操作系統上的兩個進程，調試器進程通過操作系統專門提供的調用接口（早期UNIX系統的ptrace調用、如今的進程文件系統等）控制、訪問被調試進程。后者（又稱為遠程調試），為了向系統開發人員提供靈活、方便的調試界面，調試器還是運行于通用桌面操作系統的應用程序，被調試的程序則運行于基于特定硬件平臺的嵌入式操作系統（目標操作系統）。這就帶來以下問題：調試器與被調試程序如何通信，被調試程序產生異常如何及時通知調試器，調試器如何控制、訪問被調試程序，調試器如何識別有關被調試程序的多任務信息并控制某一特定任務，調試器如何處理某些與目標硬件平臺相關的信息（如目標平臺的寄存器信息、機器代碼的反匯編等）。

我們介紹兩種遠程調試的方案，看它們怎樣解決這些問題。

調試方案

一插樁（stub）

第一種方案是在目標操作系統和調試器內分別加入某些功能模塊，二者互通信息來進行調試。上述問題可通過以下途徑解決：

調試器與被調試程序的通信
調試器與目標操作系統通過指定通信端口（串口、網卡、并口）遵循遠程調試協議進行通信。
被調試程序產生異常及時通知調試器
目標操作系統的所有異常處理最終都要轉向通信模塊，告知調試器當前的異常號；調試器據此向用戶顯示被調試程序產生了哪一類異常。
調試器控制、訪問被調試程序
調試器的這類請求實際上都將轉換成對被調試程序的地址空間或目標平臺的某些寄存器的訪問，目標操作系統接收到這樣的請求可以直接處理。對于沒有虛擬存儲概念的簡單的嵌入式操作系統而言，完成這些任務十分容易。
調試器識別有關被調試程序的多任務信息并控制某一特定任務
由目標操作系統提供相關接口。目標系統根據調試器發送的關于多任務的請求，調用該接口提供相應信息或針對某一特定任務進行控制，并返回信息給調試器。
調試器處理與目標硬件平臺相關的信息
第2條所述調試器應能根據異常號識別目標平臺產生異常的類型也屬于這一范疇，這類工作完全可以由調試器獨立完成。支持多種目標平臺正是GNUGDB的一大特色。

綜上所述，這一方案需要目標操作系統提供支持遠程調試協議的通信模塊（包括簡單的設備驅動）和多任務調試接口，并改寫異常處理的有關部分。另外目標操作系統還需要定義一個設置斷點的函數；因為有的硬件平臺提供能產生特定調試陷阱異常（debugtrap）的斷點指令以支持調試（如X86的INT3），而另一些機器沒有類似的指令，就用任意一條不能被解釋執行的非法（保留）指令代替。目標操作系統添加的這些模塊統稱為"插樁"（見下圖），駐留于ROM中則稱為ROMmonitor。通用操作系統也有具備這類模塊的：編譯運行于Alpha、Sparc或PowerPC平臺的LINUX內核時若將kgdb開關打開，就相當于加入了插樁。

圖1

運行于目標操作系統的被調試的應用程序要在入口處調用這個設置斷點的函數以產生異常，異常處理程序調用調試端口通信模塊，等待主機（host）上的調試器發送信息。雙方建立連接后調試器便等待用戶發出調試命令，目標系統等待調試器根據用戶命令生成的指令。這一過程如下圖所示。

圖2

這一方案的實質是用軟件接管目標系統的全部異常處理（exceptionhandler）及部分中斷處理，在其中插入調試端口通信模塊，與主機的調試器交互。它只能在目標操作系統初始化，特別是調試通信端口初始化完成后才起作用，所以一般只用于調試運行于目標操作系統之上的應用程序，而不宜用來調試目標操作系統，特別是無法調試目標操作系統的啟動過程。而且由于它必然要占用目標平臺的某個通信端口，該端口的通信程序就無法調試了。最關鍵的是它必須改動目標操作系統，這一改動即使沒有對操作系統在調試過程中的表現造成不利影響，至少也會導致目標系統多了一個不用于正式發布的調試版。

二片上調試（On Chip Debugging）及EmbeddedPowerPC Background Debug Mode

片上調試是在處理器內部嵌入額外的控制模塊，當滿足了一定的觸發條件時進入某種特殊狀態。在該狀態下，被調試程序停止運行，主機的調試器可以通過處理器外部特設的通信接口訪問各種資源（寄存器、存儲器等）并執行指令。為了實現主機通信端口與目標板調試通信接口各引腳信號的匹配，二者往往通過一塊簡單的信號轉換電路板連接（如下圖所示）。內嵌的控制模塊以基于微碼的監控器（microcodemonitor）或純硬件資源的形式存在，包括一些提供給用戶的接口（如斷點寄存器等）。具體產品有MotorolaCPU16、CPU32、Coldfire系列的BDM（Background Debug Mode），MotorolaPowerPC 5xx、8xx系列的EPBDM（Embedded PowerPC Background DebugMode），IBM、TI的JTAG（Joint Test ActionDebug，IEEE標準），還有OnCE、MPSD等等。下面以MPC860的EPBDM為例介紹片上調試方式。

圖3

EPBDM的運作相當于用處理器內嵌的調試模塊接管中斷及異常處理。用戶通過設置調試許可寄存器（debugenableregister）來指定哪些中斷或異常發生后處理器直接進入調試狀態，而不是操作系統的處理程序。進入調試狀態后，內嵌調試模塊向外部調試通信接口發出信號，通知一直在通信接口監聽的主機調試器，然后調試器便可通過調試模塊使處理器執行任意系統指令（相當于特權態）。所有指令均通過調試模塊獲取，所有load/store均直接訪問內存，緩存（cache）及存儲管理單元（MMU）均不可用；數據寄存器被映射為一個特殊寄存器DPDR，通過mtspr和mfspr指令訪問。調試器向處理器送rfi(returnfrom interrupt)指令便結束調試狀態，被調試程序繼續運行。

與插樁方式的缺點相對應，OCD不占用目標平臺的通信端口，無需修改目標操作系統，能調試目標操作系統的啟動過程，大大方便了系統開發人員。隨之而來的缺點是軟件工作量的增加：調試器端除了需補充對目標操作系統多任務的識別、控制等模塊，還要針對使用同一芯片的不同開發板編寫各類ROM、RAM的初始化程序。

下面就以調試運行于MPC860的LINUX為例，說明用OCD方式調試OS啟動的某些關鍵細節。

首先，LINUX內核模塊以壓縮后的zImage形式駐留于目標板的ROM，目標板上電后先運行ROM中指定位置的程序將內核移至RAM并解壓縮，然后再跳轉至內核入口處運行。要調試內核，必須在上電后ROM中的指令執行之前獲得系統的控制權，即進入調試狀態、設斷點，這樣才能開展調試過程。MPC860的EPBDM提供了這一手段。

MPC860沒有類似X86的INT3那樣能產生特定調試陷阱異常的指令，而操作系統內核往往具有針對非法指令的異常處理；為了使對內核正常運行的干擾降至最小，調試時應盡量設置硬件斷點，而不是利用非法指令產生異常的"軟"斷點。

LINUX實現了虛存管理，嵌入式LINUX往往也有這一功能。地址空間從實到虛的轉換在內核啟動過程中便完成了，不論調試內核還是應用程序，調試器都無法回避對目標系統虛地址空間的訪問，否則斷點命中時根本無法根據程序計數器的虛地址顯示當前指令，更不用說訪問變量了。由于調試狀態下轉換旁視緩沖器（TranslationLookasideBuffer）無法利用，只能仿照LINUX內核TLB失效時的異常處理程序，根據虛地址中的頁表索引位訪問特定寄存器查兩級頁表得出物理頁面號，從而完成虛實地址的轉換。MPC860采用哈佛結構（Harvardarchitecture），指令和數據緩存分離設置（因為程序的指令段和數據段是分離的，這種結構可以消除取指令和訪問數據之間的沖突），二者的TLB也分離設置；然而TLB失效時查找頁表計算物理地址的過程是相同的，因為頁表只有一個，不存在指令、數據分離的問題。虛實地址轉換這一任務雖然完全落在了調試器一方，由于上述原因，再加上調試對象是嵌入式系統，一般不會有外存設備，不必考慮內存訪問缺頁的情況，所以增加的工作量并不大。

回頁首

深入話題

傳統的調試方法可概括為如下過程：設斷點--程序暫停--觀察程序狀態--繼續運行。被調試的如果是實時系統，即使調試器支持批處理命令避免了用戶輸入命令、觀察結果帶來的延遲，它與目標系統之間的通信也完全可能錯過對目標平臺外設信號的響應。于是，針對某些調試器（如GDB）提供的監視點（tracepoint）這一特殊調試手段，目標方的插樁在原有的基礎上被改進，稱為代理（agent）。調試時用戶首先在調試器設置監視點，以源代碼表達式的形式指定感興趣的對象名。為了減少代理解析表達式的工作，調試器將表達式轉換為簡單的字節碼，傳送至代理。程序運行后命中監視點、喚醒代理，代理根據字節碼記錄用戶所需數據存入特定緩沖區（不僅僅是表達式的最終結果，還有中間結果），令程序繼續運行；這一步驟無需與調試器通信。當調試器再度得到控制時，就可以發出命令，向代理查詢歷次監視記錄。較之于插樁，代理增加了對接受到的字節碼的分析模塊，相應的目標代碼體積只有大約3K字節；當然，監視記錄緩沖區也要占用目標平臺的存儲空間，不過緩沖區的大小可在代理生成時由用戶決定。總之，這一改進以有限的目標系統資源為代價，為實時監視提供了一個低成本的可行方案。

調試并不僅僅意味著設斷點--程序暫停--觀察--繼續這一過程，往往還需要profiling、跟蹤（trace）等多種手段，而現代微處理器的技術進步卻為這些調試手段的實行帶來了困難。以跟蹤為例，其目的無非是記錄真實的程序運行流；可現代處理器指令緩存都集成于芯片內（RISC處理器尤為如此），運行指令時"取指"這一操作大多在芯片內部針對指令緩存進行，芯片外部總線上只能觀察到多條指令的預取（prefetch），預取的指令并不一定執行（由于跳轉等原因）；另外，指令往往經過動態調度后在流水線中亂序執行，如何再現其原始順序也是個問題。解決方案大致有以下三種：

有的處理器除了正常運行外，還能以串行方式運行，所有的取指周期都可呈現于片外總線（相當于禁用緩存與流水線）。這樣一來，跟蹤容易多了，處理器性能也大大降低了，根本不適用于實時要求嚴格的系統。
編譯器自動在指定的分支及函數出入口插入對特定內存區域的寫指令（與gprof等profiling工具采用的手段類似），它們都是不通過緩存而直接向內存寫的，這就能反映于芯片外總線從而被外接的邏輯分析儀記錄，最終由主機端的調試工具分析并結合符號表重構程序流。這種方法雖被廣泛使用，但畢竟是干擾式的（intrusive），對系統性能也有影響。
像上文所述的片上調試那樣，也有處理器在片內附加了跟蹤電路，收集程序流運行時的"不連貫"（discontinuities）信息（分支和異常處理的跳轉目的及源地址等），壓縮后送至特定端口，再由邏輯分析儀捕獲送至主機端調試工具重構程序流。該方案對系統性能影響最小。

總之，處理器廠家提供集成于片內的調試電路為高檔嵌入式系統開發提供各種非干擾式的調試手段早已是大勢所趨。為了解決該領域標準化的需要，一些處理器廠家、工具開發公司和儀器制造商于1998年組成了Nexus5001Forum，這是一個旨在為嵌入式控制應用產生和定義嵌入式處理器調試接口標準的聯合組織，以前的名稱是GlobalEmbedded Processor Debug Interface StandardConsortium（全球嵌入式處理器調試接口標準協會）。Nexus現在有24個成員單位，包括創始成員Motorola、InfineonTechnologies、日立、ETAS和HP等公司。該組織首先處理的是汽車動力應用所需要的調試，現在已發展成為調試數據通信、無線系統和其他實時嵌入式應用的通用接口。

參考資料