嵌入式LINUX系統(tǒng)的靜/動態(tài)集成調(diào)試模式

　　現(xiàn)有的嵌入式LINUX系統(tǒng)開發(fā)過程中，所有的工程師都疲憊于使用兩種不同的調(diào)試模式分別調(diào)試系統(tǒng)的內(nèi)核和應(yīng)用程序。首先通過一個JTAG調(diào)試工具來配置和啟動LINUX系統(tǒng)；嵌入式LINUX系統(tǒng)正常運行起來后，就要通過GDB來繼續(xù)調(diào)試工作。
　　
　　LAUTERBACH公司綜合了上述兩種傳統(tǒng)調(diào)試技術(shù)特長提供了一種新的LINUX調(diào)試技術(shù)。

　　本文以ARM架構(gòu)上的LINUX系統(tǒng)開發(fā)為例，詳細介紹和對比這三種不同的調(diào)試模式的實現(xiàn)和應(yīng)用。

靜態(tài)調(diào)試模式
　　
　　通過JTAG調(diào)試接口進行軟件調(diào)試的工具一般都只能工作在靜態(tài)調(diào)試模式下，處理器和整個系統(tǒng)都必須被同時掛起。然后調(diào)試工具通過JTAG接口把處理器和目標系統(tǒng)的當前狀態(tài)獲取并顯示出來（如圖1所示）。

　　靜態(tài)調(diào)試模式具有如下的優(yōu)點：
　　
　　● 靜態(tài)調(diào)試模式唯一的環(huán)境需求就是目標系統(tǒng)必須支持JTAG調(diào)試標準，該調(diào)試模式最大的優(yōu)點就是可以支持從復(fù)位向量表開始調(diào)試；
　　● 只要調(diào)試工具支持LINUX和MMU調(diào)試，就可以實現(xiàn)對LINUX內(nèi)核及進程越界等問題的調(diào)試；

　　● 如果軟件異常，隨時可以掛起處理器，查看當前錯誤代碼及系統(tǒng)狀態(tài)；

　　● 因為處理器處于掛起狀態(tài)，內(nèi)核和其它進程都不會再對系統(tǒng)造成任何的干擾。
　　
　　然而靜態(tài)調(diào)試模式也有其不足之處，一旦處理器被掛起，所有的通信接口進程同時被終止。造成的結(jié)果就是所有通過Ethernet、Bluetooth或者CAN等接口和處理器進行通信的外部設(shè)備， 都會因為等待響應(yīng)超時而中斷連接。因此通過靜態(tài)模式進行調(diào)試時，即使你只調(diào)試其中的一個進程或函數(shù)，也有可能改變整個系統(tǒng)的狀態(tài)和配置；接下來再繼續(xù)運行和調(diào)試程序，就無法保證系統(tǒng)的完整性和連續(xù)性，所以后續(xù)的調(diào)試可能就沒有任何意義。

動態(tài)調(diào)試模式
　　
　　GDB 調(diào)試模式是嵌入式LINUX系統(tǒng)的通用的動態(tài)調(diào)試模式。 在該模式下，可以實現(xiàn)只對當前進程掛起，系統(tǒng)的內(nèi)核和其它的所有進程都繼續(xù)處于運行狀態(tài)。
　　
　　然而GDB是一個純粹的軟件調(diào)試工具，同時需要下面的軟件環(huán)境才可以實現(xiàn)：
　　
　　● 目標系統(tǒng)上要有活動的GDB Server LINUX進程
　　
　　● 主機端要有相應(yīng)的調(diào)試軟件，例如TRACE32（如圖2所示）

　　TRACE32與GDB Server通過RS232或者Ethernet接口進行通信，收集當前被掛起的進程的狀態(tài)信息。但是要實現(xiàn)動態(tài)調(diào)試模式，還必須建立在如下兩個條件都成立的基礎(chǔ)之上：
　　
　　● 目標系統(tǒng)已經(jīng)被完全正確的初始化并正確啟動
　　
　　● GDB Server 永遠處于活動狀態(tài)——即通信接口已經(jīng)正確運行，處理器或GDB Server不會被其它程序錯誤的掛起
　　
　　綜上所述，兩種調(diào)試模式都有各自的優(yōu)點和不足，靜態(tài)調(diào)試模式比較容易實現(xiàn)，操作也比較簡單，但是無法保證系統(tǒng)的連續(xù)和完整性；動態(tài)調(diào)試模式環(huán)境需求比較復(fù)雜。因此，LAUTERBACH提供了可以實現(xiàn)上述兩種調(diào)試模式的調(diào)試工具，在完全克服了各自的缺陷的同時充分發(fā)揮了各自的優(yōu)勢，實現(xiàn)了嵌入式LINUX調(diào)試技術(shù)的飛躍。

集成的靜態(tài)和動態(tài)調(diào)試模式
　　
　　針對嵌入式LINUX系統(tǒng)，支持集成的靜態(tài)和動態(tài)調(diào)試模式的TRACE32調(diào)試工具工作原理如下（如圖3所示）：

　　1. TRACE32調(diào)試工具通過JTAG接口進入靜態(tài)調(diào)試模式。在靜態(tài)模式下首先完成對目標系統(tǒng)的硬件和動態(tài)調(diào)試模式（GDB）的環(huán)境配置。

　　2. 如果目標系統(tǒng)初始化和啟動程序是調(diào)試重點，就使用靜態(tài)調(diào)試模式進行調(diào)試。

　　3. 目標系統(tǒng)正確啟動完成后，TRACE32可以切換為動態(tài)調(diào)試模式，從而實現(xiàn)對應(yīng)用程序的動態(tài)調(diào)試。
 
　　4.如果在動態(tài)調(diào)試過程中，需要對系統(tǒng)重新做新的配置和初始化。TRACE32也支持隨時再把系統(tǒng)切換到靜態(tài)調(diào)試模式。
　　
　　同時，由于集成的靜態(tài)和動態(tài)調(diào)試模式的實現(xiàn)，下面的許多新屬性也被添加到動態(tài)調(diào)試模式里。
　　
　　● 對于基于ARM架構(gòu)的處理器，可以以調(diào)試通信通道（DCC）為動態(tài)調(diào)試模式的信息通信接口。這樣只需要一個JTAG接口就可以支持集成的靜態(tài)和動態(tài)調(diào)試模式。

　　● 對兩個或多個進程進行同時調(diào)試。

將DCC作為通信接口
　　
　　在ARM的架構(gòu)下，JTAG接口中已經(jīng)包含DCC通信接口。當應(yīng)用程序在目標處理器上運行時，從原理上講通過DCC實現(xiàn)如下兩個模塊間信息通信是完全可行的。
　　
　　● 主機端的調(diào)試軟件
　　
　　● 目標系統(tǒng)上的任何應(yīng)用程序—通過GDB Server
　　
　　因此，如果TRACE32 采用DCC 作為和GDB Server 通信的接口，就不再需要額外的通信接口來實現(xiàn)對動態(tài)調(diào)試模式的支持（如圖4所示）。

多個進程同時調(diào)試
　　
　　在實際的調(diào)試過程中，經(jīng) 常需要對多個進程進行同時的調(diào)試。為了實現(xiàn)該屬性，LAUTERBACH為動態(tài)調(diào)試模式提供了T32Server模塊。如果T32Server作為一個LINUX的進程從終端窗口中被啟動，就可以實現(xiàn)如下的命令和操作：
　　
　　● 啟動進程（TASK.RUN）
　　● 選擇運行進程（TASK.SELECT）
　　● 停止進程（TASK.KILL）

　　當一個進程被啟動并選中后，T32Server就會給每個進程分配一個獨立的GDB Server（如圖5所示），再配合上面的三條TASK操作命令就可以實現(xiàn)多個進程的同時調(diào)式。用戶可以通過命令（TASK.LIST）查看當前的進程信息。