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

調(diào)試是開發(fā)過程中必不可少的環(huán)節(jié)，通用的桌面操作系統(tǒng)與嵌入式操作系統(tǒng)在調(diào)試環(huán)境上存在明顯的差別。前者，調(diào)試器與被調(diào)試的程序往往是運行在同一臺機(jī)器、相同的操作系統(tǒng)上的兩個進(jìn)程，調(diào)試器進(jìn)程通過操作系統(tǒng)專門提供的調(diào)用接口（早期UNIX系統(tǒng)的ptrace調(diào)用、如今的進(jìn)程文件系統(tǒng)等）控制、訪問被調(diào)試進(jìn)程。后者（又稱為遠(yuǎn)程調(diào)試），為了向系統(tǒng)開發(fā)人員提供靈活、方便的調(diào)試界面，調(diào)試器還是運行于通用桌面操作系統(tǒng)的應(yīng)用程序，被調(diào)試的程序則運行于基于特定硬件平臺的嵌入式操作系統(tǒng)（目標(biāo)操作系統(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)試器如何處理某些與目標(biāo)硬件平臺相關(guān)的信息（如目標(biāo)平臺的寄存器信息、機(jī)器代碼的反匯編等）。 我們介紹兩種遠(yuǎn)程調(diào)試的方案，看它們怎樣解決這些問題。

調(diào)試方案

 ? ?一 插樁（stub）

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

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

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

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

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

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

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

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

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

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

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

? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?圖1 系統(tǒng)結(jié)構(gòu)

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

? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?圖2 指令流程圖

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

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

片上調(diào)試是在處理器內(nèi)部嵌入額外的控制模塊，當(dāng)滿足了一定的觸發(fā)條件時進(jìn)入某種特殊狀態(tài)。在該狀態(tài)下，被調(diào)試程序停止運行，主機(jī)的調(diào)試器可以通過處理器外部特設(shè)的通信接口訪問各種資源（寄存器、存儲器等）并執(zhí)行指令。為了實現(xiàn)主機(jī)通信端口與目標(biāo)板調(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標(biāo)準(zhǔn)），還有OnCE、MPSD等等。下面以MPC860的EPBDM為例介紹片上調(diào)試方式。

? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?圖3? ?

EPBDM的運作相當(dāng)于用處理器內(nèi)嵌的調(diào)試模塊接管中斷及異常處理。用戶通過設(shè)置調(diào)試許
可寄存器（debug enable register）來指定哪些中斷或異常發(fā)生后處理器直接進(jìn)入調(diào)試狀態(tài)，而不是操作系統(tǒng)的處理程序。進(jìn)入調(diào)試狀態(tài)后，內(nèi)嵌調(diào)試模塊向外部調(diào)試通信接口發(fā)出信號，通知一直在通信接口監(jiān)聽的主機(jī)調(diào)試器，然后調(diào)試器便可通過調(diào)試模塊使處理器執(zhí)行任意系統(tǒng)指令（相當(dāng)于特權(quán)態(tài)）。所有指令均通過調(diào)試模塊獲取，所有l(wèi)oad/store 均直接訪問內(nèi)存，緩存（cache）及存儲管理單元（MMU）均不可用；數(shù)據(jù)寄存器被映射為一個特殊寄存器DPDR，通過mtspr和mfspr指令訪問。調(diào)試器向處理器送rfi(return from interrupt)指令便結(jié)束調(diào)試狀態(tài)，被調(diào)試程序繼續(xù)運行。

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

下面就以調(diào)試運行于MPC860的LINUX為例，說明用OCD方式調(diào)試OS 啟動的某些關(guān)鍵細(xì)節(jié)。

首先，LINUX內(nèi)核模塊以壓縮后的zImage形式駐留于目標(biāo)板的ROM，目標(biāo)板上電后先運行ROM中指定位置的程序?qū)?nèi)核移至RAM并解壓縮，然后再跳轉(zhuǎn)至內(nèi)核入口處運行。要調(diào)試內(nèi)核，必須在上電后ROM中的指令執(zhí)行之前獲得系統(tǒng)的控制權(quán)，即進(jìn)入調(diào)試狀態(tài)、設(shè)斷點，這樣才能開展調(diào)試過程。MPC860的EPBDM提供了這一手段。

MPC860沒有類似X86的INT 3那樣能產(chǎn)生特定調(diào)試陷阱異常的指令，而操作系統(tǒng)內(nèi)核往往具有針對非法指令的異常處理；為了使對內(nèi)核正常運行的干擾降至最小，調(diào)試時應(yīng)盡量設(shè)置硬件斷點，而不是利用非法指令產(chǎn)生異常的"軟"斷點。

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

深入話題

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

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

有的處理器除了正常運行外，還能以串行方式運行，所有的取指周期都可呈現(xiàn)于片外總線（相當(dāng)于禁用緩存與流水線）。這樣一來，跟蹤容易多了，處理器性能也大大降低了，根本不適用于實時要求嚴(yán)格的系統(tǒng)。

編譯器自動在指定的分支及函數(shù)出入口插入對特定內(nèi)存區(qū)域的寫指令（與gprof等profiling工具采用的手段類似），它們都是不通過緩存而直接向內(nèi)存寫的，這就能反映于芯片外總線從而被外接的邏輯分析儀記錄，最終由主機(jī)端的調(diào)試工具分析并結(jié)合符號表重構(gòu)程序流。這種方法雖被廣泛使用，但畢竟是干擾式的（intrusive），對系統(tǒng)性能也有影響。

像上文所述的片上調(diào)試那樣，也有處理器在片內(nèi)附加了跟蹤電路，收集程序流運行時的"不連貫"（discontinuities）信息（分支和異常處理的跳轉(zhuǎn)目的及源地址等），壓縮后送至特定端口，再由邏輯分析儀捕獲送至主機(jī)端調(diào)試工具重構(gòu)程序流。該方案對系統(tǒng)性能影響最小。

總之，處理器廠家提供集成于片內(nèi)的調(diào)試電路為高檔嵌入式系統(tǒng)開發(fā)提供各種非干擾式的調(diào)試手段早已是大勢所趨。為了解決該領(lǐng)域標(biāo)準(zhǔn)化的需要，一些處理器廠家、工具開發(fā)公司和儀器制造商于1998年組成了Nexus 5001 Forum，這是一個旨在為嵌入式控制應(yīng)用產(chǎn)生和定義嵌入式處理器調(diào)試接口標(biāo)準(zhǔn)的聯(lián)合組織，以前的名稱是Global Embedded Processor Debug Interface Standard Consortium（全球嵌入式處理器調(diào)試接口標(biāo)準(zhǔn)協(xié)會）。Nexus現(xiàn)在有24個成員單位，包括創(chuàng)始成員Motorola、Infineon Technologies、日立、ETAS和HP等公司。該組織首先處理的是汽車動力應(yīng)用所需要的調(diào)試，現(xiàn)在已發(fā)展成為調(diào)試數(shù)據(jù)通信、無線系統(tǒng)和其他實時嵌入式應(yīng)用的通用接口。