新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計應(yīng)用 > 嵌入式操作系統(tǒng)的調(diào)試問題分析

嵌入式操作系統(tǒng)的調(diào)試問題分析

作者: 時間:2010-08-08 來源:網(wǎng)絡(luò) 收藏
是開發(fā)過程中必不可少的環(huán)節(jié),通用的桌面環(huán)境上存在明顯的差別。前者,器與被調(diào)試的程序往往是運行在同一臺機器、相同的上的兩個進程,調(diào)試器進程通過操作系統(tǒng)專門提供的調(diào)用接口(早期UNIX系統(tǒng)的ptrace調(diào)用、如今的進程文件系統(tǒng)等)控制、訪問被調(diào)試進程。后者(又稱為遠程調(diào)試),為了向系統(tǒng)開發(fā)人員提供靈活、方便的調(diào)試界面,調(diào)試器還是運行于通用桌面操作系統(tǒng)的應(yīng)用程序,被調(diào)試的程序則運行于基于特定硬件平臺的操作系統(tǒng)(目標操作系統(tǒng))。這就帶來以下:調(diào)試器與被調(diào)試程序如何通信,被調(diào)試程序產(chǎn)生異常如何及時通知調(diào)試器,調(diào)試器如何控制、訪問被調(diào)試程序,調(diào)試器如何識別有關(guān)被調(diào)試程序的多任務(wù)信息并控制某一特定任務(wù),調(diào)試器如何處理某些與目標硬件平臺相關(guān)的信息(如目標平臺的寄存器信息、機器代碼的反匯編等)。 我們介紹兩種遠程調(diào)試的方案,看它們怎樣解決這些。

調(diào)試方案

nbsp; 一 插樁(stub)

第一種方案是在目標操作系統(tǒng)和調(diào)試器內(nèi)分別加入某些功能模塊,二者互通信息來進行調(diào)試。上述可通過以下途徑解決:

(1)調(diào)試器與被調(diào)試程序的通信

調(diào)試器與目標操作系統(tǒng)通過指定通信端口(串口、網(wǎng)卡、并口)遵循遠程調(diào)試協(xié)議進行通信(遠程調(diào)試協(xié)議。
(2)被調(diào)試程序產(chǎn)生異常及時通知調(diào)試器

目標操作系統(tǒng)的所有異常處理最終都要轉(zhuǎn)向通信模塊,告知調(diào)試器當前的異常號;調(diào)試器據(jù)此向用戶顯示被調(diào)試程序產(chǎn)生了哪一類異常。

(3)調(diào)試器控制、訪問被調(diào)試程序

調(diào)試器的這類請求實際上都將轉(zhuǎn)換成對被調(diào)試程序的地址空間或目標平臺的某些寄存器的訪問,目標操作系統(tǒng)接收到這樣的請求可以直接處理。對于沒有虛擬存儲概念的簡單的操作系統(tǒng)而言,完成這些任務(wù)十分容易。

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

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

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

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

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


本文引用地址:http://butianyuan.cn/article/151701.htm 圖1 系統(tǒng)結(jié)構(gòu)

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


圖2 指令流程圖


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

二 片上調(diào)試(On Chip Debugging)及Embedded PowerPC Background Debug Mode

片上調(diào)試是在處理器內(nèi)部嵌入額外的控制模塊,當滿足了一定的觸發(fā)條件時進入某種特殊狀態(tài)。在該狀態(tài)下,被調(diào)試程序停止運行,主機的調(diào)試器可以通過處理器外部特設(shè)的通信接口訪問各種資源(寄存器、存儲器等)并執(zhí)行指令。為了實現(xiàn)主機通信端口與目標板調(diào)試通信接口各引腳信號的匹配,二者往往通過一塊簡單的信號轉(zhuǎn)換電路板連接(如下圖所示)。內(nèi)嵌的控制模塊以基于微碼的監(jiān)控器(microcode monitor)或純硬件資源的形式存在,包括一些提供給用戶的接口(如斷點寄存器等)。具體產(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為例介紹片上調(diào)試方式。

圖3
linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解(linux不再難懂)

上一頁 1 2 下一頁

評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉