深入話題
傳統的調試方法可概括為如下過程：設斷點--程序暫停--觀察程序狀態--繼續運行。被調試的如果是實時系統，即使調試器支持批處理命令避免了用戶輸入命令、觀察結果帶來的延遲，它與目標系統之間的通信也完全可能錯過對目標平台外設信號的響應。於是，針對某些調試器（如GDB）提供的監視點（trace point）這一特殊調試手段，目標方的插樁在原有的基礎上被改進，稱為代理（agent）。調試時用戶首先在調試器設置監視點，以源代碼表達式的形式指定感興趣的對象名。為了減少代理解析表達式的工作，調試器將表達式轉換為簡單的字節碼，傳送至代理。程序運行後命中監視點、喚醒代理，代理根據字節碼記錄用戶所需數據存入特定緩沖區（不僅僅是表達式的最終結果，還有中間結果），令程序繼續運行；這一步驟無需與調試器通信。當調試器再度得到控制時，就可以發出命令，向代理查詢歷次監視記錄。較之於插樁，代理增加了對接受到的字節碼的分析模塊，相應的目標代碼體積只有大約3K字節；當然，監視記錄緩沖區也要占用目標平台的存儲空間，不過緩沖區的大小可在代理生成時由用戶決定。總之，這一改進以有限的目標系統資源為代價，為實時監視提供了一個低成本的可行方案。
調試並不僅僅意味著設斷點--程序暫停--觀察--繼續這一過程，往往還需要profiling、跟蹤（trace）等多種手段，而現代微處理器的技術進步卻為這些調試手段的實行帶來了困難。以跟蹤為例，其目的無非是記錄真實的程序運行流；可現代處理器指令緩存都集成於芯片內（RISC處理器尤為如此），運行指令時"取指"這一操作大多在芯片內部針對指令緩存進行，芯片外部總線上只能觀察到多條指令的預取（prefetch），預取的指令並不一定執行（由於跳轉等原因）；另外，指令往往經過動態調度後在流水線中亂序執行，如何再現其原始順序也是個問題。解決方案大致有以下三種：
1.有的處理器除了正常運行外，還能以串行方式運行，所有的取指周期都可呈現於片外總線（相當於禁用緩存與流水線）。這樣一來，跟蹤容易多了，處理器性能也大大降低了，根本不適用於實時要求嚴格的系統。
2.編譯器自動在指定的分支及函數出入口插入對特定內存區域的寫指令（與gprof等profiling工具采用的手段類似），它們都是不通過緩存而直接向內存寫的，這就能反映於芯片外總線從而被外接的邏輯分析儀記錄，最終由主機端的調試工具分析並結合符號表重構程序流。這種方法雖被廣泛使用，但畢竟是干擾式的（intrusive），對系統性能也有影響。
3.像上文所述的片上調試那樣，也有處理器在片內附加了跟蹤電路，收集程序流運行時的"不連貫"（discontinuities）信息（分支和異常處理的跳轉目的及源地址等），壓縮後送至特定端口，再由邏輯分析儀捕獲送至主機端調試工具重構程序流。該方案對系統性能影響最小。
總之，處理器廠家提供集成於片內的調試電路為高檔嵌入式系統開發提供各種非干擾式的調試手段早已是大勢所趨。為了解決該領域標准化的需要，一些處理器廠家、工具開發公司和儀器制造商於1998年組成了Nexus 5001 Forum，這是一個旨在為嵌入式控制應用產生和定義嵌入式處理器調試接口標准的聯合組織，以前的名稱是Global Embedded Processor Debug Interface Standard Consortium（全球嵌入式處理器調試接口標准協會）。Nexus現在有24個成員單位，包括創始成員Motorola、Infineon Technologies、日立、ETAS和HP等公司。該組織首先處理的是汽車動力應用所需要的調試，現在已發展成為調試數據通信、無線系統和其他實時嵌入式應用的通用接口。
參考文獻
MPC860 PowerQUICC User's Manual MOTOROLA
http://www.vas-gmbh.de/software/mpcbdm/
http://www.metrowerks.com/tools/documentation/embedded/zenofbdm
http://www.redhat.com/support/wpapers/cygnus_heinsenberg/trace.Html
http://www.ednmag.com/reg/2000/05112000/10tt.htm
作者簡介
熊競，任職於中科院計算所嵌入式系統軟件組。主要從事開發嵌入式操作系統的仿真器、調試器及集成開發環境。您可以通過電子郵件
[email protected]與他聯系。
