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

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

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

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

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