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

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

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

3.1.1 初始化模塊
　　修改異常處理" title="異常處理">異常處理函數(shù)，使得異常發(fā)生時進入函數(shù)handle_exception( )，GDB就能夠捕獲這些異常。初始化后使用breakpoint( )函數(shù)將系統(tǒng)控制權直接交給GDB。KGDB對異常處理函數(shù)的修改基本上可以分為二種，這兩種方式均需先定義宏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的處理函數(shù)為例。
　　#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；
　　}
　　由以上代碼可見，進入內核調試狀態(tài)后，異常處理函數(shù)就是handle_exception( )，程序流程跳過了非調試狀態(tài)時的處理函數(shù)do_trap( )。
　　(2)不改變程序的流程，以異常divide_error 的處理函數(shù)為例。
　　#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，F(xiàn)PE_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)；
　　}
　　從以上代碼看不出調試狀態(tài)與非調試狀態(tài)的區(qū)別，可以看一下do_trap函數(shù)可能會調用的函數(shù)die( )。
　　void die(const char*str，struct pt_regs*regs，long err)
　　{ ……
　　CHK_REMOTE_DEBUG(1，SIGTRAP，err，regs，)
　　……
　　do_exit(SIGSEGV)；
　　}
　　由此可見，調試狀態(tài)下的異常處理函數(shù)還是進入了handle_exception函數(shù)。不過與上面一種異常不同之處在于：異常處理函數(shù)在調試與非調試狀態(tài)下的程序流程是相同的，handle_exception只獲取系統(tǒng)當時的狀態(tài)，繼續(xù)運行的結果還是do_exit。
　　雖然不是所有異常函數(shù)都是按上述兩種方法定義，但本質上都一樣。絕大多數(shù)處理函數(shù)的修改屬于第二種，因為第一種異常是為調試準備的。因此在目標機具有調試輸出設備的情況下，完全可以不修改第二種異常處理函數(shù)。因為Linux內核在非調試狀態(tài)下的異常處理函數(shù)已經(jīng)輸出必要的狀態(tài)信息、出錯信息。
3.1.2 控制模塊
　　控制模塊與主機GDB通信的具體流程如圖4。KGDB只調試內核態(tài)程序。handle_exception函數(shù)首先判斷CPU是否處于VM86模式或用戶態(tài)，若是則返回；然后接收GDB發(fā)來的信息，根據(jù)接收的信息作出相應的操作和回復。流程圖內的虛線框是所有GDBstub中handle_exception函數(shù)的通用流程。

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