嵌入式操作系統的調試問(wèn)題及解決方法

調試是開(kāi)發(fā)過(guò)程中必不可少的環(huán)節，通用的桌面操作系統與嵌入式操作系統在調試環(huán)境上存在明顯的差別。前者，調試器與被調試的程序往往是運行在同一臺機器、相同的操作系統上的兩個(gè)進(jìn)程，調試器進(jìn)程通過(guò)操作系統專(zhuān)門(mén)提供的調用接口（早期UNIX系統的ptrace調用、如今的進(jìn)程文件系統等）控制、訪(fǎng)問(wèn)被調試進(jìn)程。后者（又稱(chēng)為遠程調試），為了向系統開(kāi)發(fā)人員提供靈活、方便的調試界面，調試器還是運行于通用桌面操作系統的應用程序，被調試的程序則運行于基于特定硬件平臺的嵌入式操作系統（目標操作系統）。這就帶來(lái)以下問(wèn)題：調試器與被調試程序如何通信，被調試程序產(chǎn)生異常如何及時(shí)通知調試器，調試器如何控制、訪(fǎng)問(wèn)被調試程序，調試器如何識別有關(guān)被調試程序的多任務(wù)信息并控制某一特定任務(wù)，調試器如何處理某些與目標硬件平臺相關(guān)的信息（如目標平臺的寄存器信息、機器代碼的反匯編等）。 我們介紹兩種遠程調試的方案，看它們怎樣解決這些問(wèn)題。

調試方案

一 插樁（stub）

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

（1）調試器與被調試程序的通信

調試器與目標操作系統通過(guò)指定通信端口（串口、網(wǎng)卡、并口）遵循遠程調試協(xié)議進(jìn)行通信（遠程調試協(xié)議。
（2）被調試程序產(chǎn)生異常及時(shí)通知調試器

目標操作系統的所有異常處理最終都要轉向通信模塊，告知調試器當前的異常號；調試器據此向用戶(hù)顯示被調試程序產(chǎn)生了哪一類(lèi)異常。

（3）調試器控制、訪(fǎng)問(wèn)被調試程序

調試器的這類(lèi)請求實(shí)際上都將轉換成對被調試程序的地址空間或目標平臺的某些寄存器的訪(fǎng)問(wèn)，目標操作系統接收到這樣的請求可以直接處理。對于沒(méi)有虛擬存儲概念的簡(jiǎn)單的嵌入式操作系統而言，完成這些任務(wù)十分容易。

（4）調試器識別有關(guān)被調試程序的多任務(wù)信息并控制某一特定任務(wù)

由目標操作系統提供相關(guān)接口。目標系統根據調試器發(fā)送的關(guān)于多任務(wù)的請求，調用該接口提供相應信息或針對某一特定任務(wù)進(jìn)行控制，并返回信息給調試器。

（5）調試器處理與目標硬件平臺相關(guān)的信息

第2條所述調試器應能根據異常號識別目標平臺產(chǎn)生異常的類(lèi)型也屬于這一范疇，這類(lèi)工作完全可以由調試器獨立完成。支持多種目標平臺正是GNU GDB的一大特色。

綜上所述，這一方案需要目標操作系統提供支持遠程調試協(xié)議的通信模塊（包括簡(jiǎn)單的設備驅動(dòng)）和多任務(wù)調試接口，并改寫(xiě)異常處理的有關(guān)部分。另外目標操作系統還需要定義一個(gè)設置斷點(diǎn)的函數；因為有的硬件平臺提供能產(chǎn)生特定調試陷阱異常（debug trap）的斷點(diǎn)指令以支持調試（如X86的INT 3），而另一些機器沒(méi)有類(lèi)似的指令，就用任意一條不能被解釋執行的非法（保留）指令代替。目標操作系統添加的這些模塊統稱(chēng)為插樁（見(jiàn)下圖），駐留于ROM中則稱(chēng)為ROM monitor。通用操作系統也有具備這類(lèi)模塊的：編譯運行于A(yíng)lpha、Sparc或PowerPC平臺的LINUX內核時(shí)若將kgdb開(kāi)關(guān)打開(kāi)，就相當于加入了插樁。

圖1 系統結構

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

圖2 指令流程圖


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

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

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

圖3