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

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

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

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

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