調試是開發過程中必不可少的環節，然而內核、嵌入式系統的調試不同于傳統的調試系統。通常嵌入式系統不具備使用本地調試器" title="調試器">調試器的能力，原因如下：
　　(1)系統自身的資源有限，內存小，輸入輸出設備不能用于調試。
　　(2)傳統的調試系統需要文件系統，而嵌入式系統通常無文件系統，內核調試時還不支持文件系統。
　　(3)調試器的運行本身需要操作系統的支持，因此無法實現操作系統內核的調試。
　　最有效的解決方法是采用遠程調試技術。遠程調試是指調試器運行的環境(主機)與被調試的系統(目標機)在物理上是分離的、通過串口或者網絡進行連接的調試技術。
　　GNU免費提供的GDB擁有強大的遠程調試功能，它能夠使開發人員以遠程調試的方式單步執行目標平臺上的程序代碼、設置斷點、查看內存，并與目標平臺交換信息。GDB遠程調試的實時、動態、方便、免費等優點，使它逐漸成為嵌入式開發首選的調試方案。
　　遠程調試系統由三部分組成：主機上的本地調試器、目標機上的調試代理、遠程調試協議，如圖1所示。對應GDB遠程調試系統的三部分為：GDB、GDBstub、GDB遠程串行協議。下面就這三部分進行分析。

1 RSP協議
　　GDB RSP(Remote Serial Protocol)定義了GDB宿主機與被調試目標機進行通信時數據包的格式。信息的格式是：＄數據#校驗碼。多數信息使用ASCII碼，數據由一系列的ASCII碼組成，校驗碼是由兩個16進制數組成的單字節校驗碼。接收方接收數據并校驗，若正確則回應“＋”，否則回應“－”。通信的內容包括讀寫數據、控制程序運行、報告程序狀態等命令。RSP的基本命令從通信對話角度可以分為兩種：
　　(1)請求
　　?：讀當前系統狀態
　　g：讀所有寄存器
　　G〈register_data〉：寫所有寄存器
　　m〈address〉，〈length〉：讀內存
　　M〈address〉，〈length〉：〈memory_data〉：寫內存
　　c：繼續執行
　　s：單步執行
　　k：終止進程
　　(2)答復
　　“”：告訴GDB上次請求命令不支持。
　　E：告訴GDB出錯
　　OK：上次請求正確
　　W〈exit_status〉：系統在“exit_status”狀態下退出。
　　X〈signal〉：系統在signal信號下終止。
　　S〈signal〉：系統在signal信號下停止。
　　O：告訴GDB控制臺輸出，這也是惟一向GDB發出的命令。
2 GDB遠程調試功能
　　調試內核時通常還沒有文件系統，而且多數嵌入式系統由于自身資源的限制不具備文件系統，因此將與文件系統有關的源文件、目標文件及符號表都存放在主機上，由主機上的調試器處理。同樣，調試用的輸入輸出設備也是由主機提供。主機上的調試器接收用戶輸入的調試命令并進行預處理，對于某些命令(如breakpoint)的處理在主機GDB上實現，不需要與目標機通信。當然，更多的指令需要在目標機調試代理上實現。主機根據RSP對預處理之后的命令進行封裝，發送給目標機上的調試代理，調試代理接收命令后作相應的處理，并返回信息給主機上的調試器。
3 目標機上stub的實現
　　目標機上stub的基本功能是與主機GDB通信，實現讀寫內存、寄存器，stop、continue指令。主機GDB與目標機上stub通信的通用模型如圖2。

　　目標機與主機通過硬件連接，被調試部分插入stub，GDB與被調試部分通過RSP通信。根據stub所處層的不同實現不同層的調試，包括內核層、應用層的調試。
3.1 內核層調試模型
　　內核層調試模型如圖3，將stub插入到內核可以實現內核的調試。Linux內核調試機制KGDB就是使用這種模式。KGDB可以分為初始化模塊和控制模塊。

3.1.1 初始化模塊
　　修改異常處理" title="異常處理">異常處理函數，使得異常發生時進入函數handle_exception( )，GDB就能夠捕獲這些異常。初始化后使用breakpoint( )函數將系統控制權直接交給GDB。KGDB對異常處理函數的修改基本上可以分為二種，這兩種方式均需先定義宏CHK_REMOTE_DEBUG：
　　#define CHK_REMOTE_DEBUG(trapnr，signr，error_code，regs，after) \
　　{ if(linux_debug_hook!=(gdb_debug_hook*) NULL && \
　　　　!user_mode(regs)) \
　　　　{ (*linux_debug_hook)(trapnr，signr，error_code，regs)；\
　　　　　　after；\
　　　　}\
　　}
　　(1)改變程序的流程，以int3的處理函數為例。
　　#define DO_VM86_ERROR(trapnr，signr，str，name) \
　　asmlinkage void do_##name(struct pt_regs*regs，long \
　　error_code) \
　　{ \
　　CHK_REMOTE_DEBUG(trapnr，signr，error_code，regs，goto skip_trap)\
　　do_trap(trapnr，signr，str，1，regs，error_code，NULL)；\
　　skip_trap：\
　　return；\
　　}
　　展開DO_VM86_ERROR(3，SIGTRAP，″int3″，int3)
　　asmlinkage void do_int3(struct pt_regs*regs，long
　　error_code)
　　{ if(linux_debug_hook！=(gdb_debug_hook*)NULL&&!
　　user_mode(regs))
　　{ (*linux_debug_hook)(3，SIGTRAP，errorcode，regs)；
　　　　goto skip_trap；
　　}
　　do_trap(3，SIGTRAP，″int3″，1，regs，error_code，NULL)；
　　skip_trap：
　　return；
　　}
　　由以上代碼可見，進入內核調試狀態后，異常處理函數就是handle_exception( )，程序流程跳過了非調試狀態時的處理函數do_trap( )。
　　(2)不改變程序的流程，以異常divide_error 的處理函數為例。
　　#define DO_VM86_ERROR_INFO(trapnr，signr，str，name，sicode，siaddr) \
　　asmlinkage void do_##name(struct pt_regs*regs，long error_code) \
　　{ ……\
　　do_trap(trapnr，signr，str，1，regs，error_code，&info)； \
　　}
　　展開DO_VM86_ERROR_INFO( 0，SIGFPE，″divide error″，
　　divide_error，FPE_INTDIV，regs-〉eip)
　　asmlinkage void do_divide_error(struct pt_regs*regs，long
　　error_code)
　　{ if(linux_debug_hook！=(gdb_debug_hook*)NULL&&! user_mode(regs))
　　{ (*linux_debug_hook)(3，SIGTRAP，errorcode，regs)；
　　}
　　do_trap(0，SIGTRAP，″divide erro″，1，regs，error_code，&info)；
　　}
　　從以上代碼看不出調試狀態與非調試狀態的區別，可以看一下do_trap函數可能會調用的函數die( )。
　　void die(const char*str，struct pt_regs*regs，long err)
　　{ ……
　　CHK_REMOTE_DEBUG(1，SIGTRAP，err，regs，)
　　……
　　do_exit(SIGSEGV)；
　　}
　　由此可見，調試狀態下的異常處理函數還是進入了handle_exception函數。不過與上面一種異常不同之處在于：異常處理函數在調試與非調試狀態下的程序流程是相同的，handle_exception只獲取系統當時的狀態，繼續運行的結果還是do_exit。
　　雖然不是所有異常函數都是按上述兩種方法定義，但本質上都一樣。絕大多數處理函數的修改屬于第二種，因為第一種異常是為調試準備的。因此在目標機具有調試輸出設備的情況下，完全可以不修改第二種異常處理函數。因為Linux內核在非調試狀態下的異常處理函數已經輸出必要的狀態信息、出錯信息。
3.1.2 控制模塊
　　控制模塊與主機GDB通信的具體流程如圖4。KGDB只調試內核態程序。handle_exception函數首先判斷CPU是否處于VM86模式或用戶態，若是則返回；然后接收GDB發來的信息，根據接收的信息作出相應的操作和回復。流程圖內的虛線框是所有GDBstub中handle_exception函數的通用流程。

3.2 應用程序調試模型
　　在嵌入式Linux開發領域中調試應用程序常用調試代理工具GDBserver。其工作原理不是在被調試應用程序內編譯stub，而是把被調試程序作為GDBserver的子進程，這樣GDBserver可以利用內核提供的代碼跟蹤機制(ptrace)監控被調試進程的運行，從而完成調試任務。此工作原理與GDB本地調試相似。其調試模型如圖5。GDBserver的工作流程是：GDBserver創建子進程－〉綁定跟蹤ptrace(ptrace_traceme，，)－〉從主機傳來的各種調試命令通過GDBserver轉化為各種操作需求的ptrace。如果用GDBserver進行遠程調試，需要內核操作系統的支持，包括子進程、代碼跟蹤機制，這樣其他嵌入式系統內核工作量會較大。而且ptrace也有其局限性，例如只能跟蹤子進程，在調試進程與被調試進程之間傳送一個長字的數據。使用通用的調試模式工作量會更小。如圖6，在應用程序中編譯stub，并在應用程序入口處插入斷點，程序開始將控制權交給GDB，之后的流程與內核層調試類似。