LAUTERBACH公司綜合了上述兩種傳統調試技術特長提供了一種新的LINUX調試技術。
本文以ARM架構上的LINUX系統開發為例,詳細介紹和對比這三種不同的調試模式的實現和應用。
靜態調試模式
通過JTAG調試接口進行軟件調試的工具一般都只能工作在靜態調試模式下,處理器和整個系統都必須被同時掛起。然後調試工具通過JTAG接口把處理器和目標系統的當前狀態獲取並顯示出來(如圖1所示)。
靜態調試模式具有如下的優點:
靜態調試模式唯一的環境需求就是目標系統必須支持JTAG調試標准,該調試模式最大的優點就是可以支持從復位向量表開始調試;
只要調試工具支持LINUX和MMU調試,就可以實現對LINUX內核及進程越界等問題的調試;
如果軟件異常,隨時可以掛起處理器,查看當前錯誤代碼及系統狀態;
因為處理器處於掛起狀態,內核和其它進程都不會再對系統造成任何的干擾。
然而靜態調試模式也有其不足之處,一旦處理器被掛起,所有的通信接口進程同時被終止。造成的結果就是所有通過Ethernet、Bluetooth或者CAN等接口和處理器進行通信的外部設備, 都會因為等待響應超時而中斷連接。因此通過靜態模式進行調試時,即使你只調試其中的一個進程或函數,也有可能改變整個系統的狀態和配置;接下來再繼續運行和調試程序,就無法保證系統的完整性和連續性,所以後續的調試可能就沒有任何意義。
動態調試模式
GDB 調試模式是嵌入式LINUX系統的通用的動態調試模式。 在該模式下,可以實現只對當前進程掛起,系統的內核和其它的所有進程都繼續處於運行狀態。
然而GDB是一個純粹的軟件調試工具,同時需要下面的軟件環境才可以實現:
目標系統上要有活動的GDB Server LINUX進程
主機端要有相應的調試軟件,例如TRACE32(如圖2所示)
TRACE32與GDB Server通過RS232或者Ethernet接口進行通信,收集當前被掛起的進程的狀態信息。但是要實現動態調試模式,還必須建立在如下兩個條件都成立的基礎之上:
目標系統已經被完全正確的初始化並正確啟動
GDB Server 永遠處於活動狀態——即通信接口已經正確運行,處理器或GDB Server不會被其它程序錯誤的掛起
綜上所述,兩種調試模式都有各自的優點和不足,靜態調試模式比較容易實現,操作也比較簡單,但是無法保證系統的連續和完整性;動態調試模式環境需求比較復雜。因此,LAUTERBACH提供了可以實現上述兩種調試模式的調試工具,在完全克服了各自的缺陷的同時充分發揮了各自的優勢,實現了嵌入式LINUX調試技術的飛躍。
集成的靜態和動態調試模式
針對嵌入式LINUX系統,支持集成的靜態和動態調試模式的TRACE32調試工具工作原理如下(如圖3所示):
1. TRACE32調試工具通過JTAG接口進入靜態調試模式。在靜態模式下首先完成對目標系統的硬件和動態調試模式(GDB)的環境配置。
3. 目標系統正確啟動完成後,TRACE32可以切換為動態調試模式,從而實現對應用程序的動態調試。
4.如果在動態調試過程中,需要對系統重新做新的配置和初始化。TRACE32也支持隨時再把系統切換到靜態調試模式。
同時,由於集成的靜態和動態調試模式的實現,下面的許多新屬性也被添加到動態調試模式裡。
對於基於ARM架構的處理器,可以以調試通信通道(DCC)為動態調試模式的信息通信接口。這樣只需要一個JTAG接口就可以支持集成的靜態和動態調試模式。
對兩個或多個進程進行同時調試。
將DCC作為通信接口
在ARM的架構下,JTAG接口中已經包含DCC通信接口。當應用程序在目標處理器上運行時,從原理上講通過DCC實現如下兩個模塊間信息通信是完全可行的。
主機端的調試軟件
目標系統上的任何應用程序—通過GDB Server
因此,如果TRACE32 采用DCC 作為和GDB Server 通信的接口,就不再需要額外的通信接口來實現對動態調試模式的支持(如圖4所示)。
多個進程同時調試
在實際的調試過程中,經 常需要對多個進程進行同時的調試。為了實現該屬性,LAUTERBACH為動態調試模式提供了T32Server模塊。如果T32Server作為一個LINUX的進程從終端窗口中被啟動,就可以實現如下的命令和操作:
啟動進程(TASK.RUN)
選擇運行進程(TASK.SELECT)
停止進程(TASK.KILL)
當一個進程被啟動並選中後,T32Server就會給每個進程分配一個獨立的GDB Server(如圖5所示),再配合上面的三條TASK操作命令就可以實現多個進程的同時調式。用戶可以通過命令(TASK.LIST)查看當前的進程信息。