現有的嵌入式LINUX系統開發過程中，所有的工程師都疲憊于使用兩種不同的調試模式分別調試系統的內核和應用程序。首先通過一個JTAG調試工具來配置和啟動LINUX系統；嵌入式LINUX系統正常運行起來后，就要通過GDB來繼續調試工作。
　　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調試技術的飛躍。