Labs 導(dǎo)讀

Debug調(diào)試覆蓋了整個(gè)計(jì)算機(jī)領(lǐng)域，包括不限于數(shù)字電路、模擬仿真、嵌入式軟硬件以及應(yīng)用軟件，是技術(shù)研發(fā)人員必須熟練掌握的重要技能，對(duì)于產(chǎn)品研發(fā)過程的代碼糾錯(cuò)和產(chǎn)品質(zhì)量把控有重要影響，本文主要探討分析主流硬件平臺(tái)和操作系統(tǒng)的軟件程序Debug原理。

1

Bug和Debug

說起“Debug”，就不得不提及“Bug”這個(gè)程序猿和游戲玩家耳熟能詳?shù)脑~，它由美國(guó)格蕾絲·赫柏博士第一次提出，當(dāng)時(shí)運(yùn)行研究數(shù)據(jù)的Harvard Mark II計(jì)算機(jī)突然不能正常工作，經(jīng)赫柏和團(tuán)隊(duì)的反復(fù)排查，發(fā)現(xiàn)是一只飛蛾飛入了電腦的內(nèi)部繼電器中造成短路而引起的故障。

修復(fù)故障后，赫柏在日記中詼諧地記錄下了這件事（圖1）， “Bug”一詞（原意為“蟲子”）也逐漸被廣泛用于形容計(jì)算機(jī)程序中隱藏的錯(cuò)誤，同時(shí)，受到從電腦中驅(qū)除飛蛾蟲子的啟發(fā)，計(jì)算機(jī)術(shù)語“Debug”（調(diào)試排錯(cuò)）開始使用。

圖1

Debug調(diào)試覆蓋了整個(gè)計(jì)算機(jī)領(lǐng)域，包括不限于數(shù)字電路、模擬仿真、嵌入式軟硬件以及應(yīng)用軟件，是技術(shù)研發(fā)人員必須熟練掌握的重要技能，對(duì)于產(chǎn)品研發(fā)過程的代碼糾錯(cuò)和產(chǎn)品質(zhì)量把控有重要影響，本文主要探討分析主流硬件平臺(tái)和操作系統(tǒng)的軟件程序Debug原理。

2

調(diào)試原理-斷點(diǎn)

對(duì)于如C、C++等編譯運(yùn)行的可執(zhí)行程序，其Debug斷點(diǎn)調(diào)試需要硬件和操作系統(tǒng)的支持，主要依賴以下兩點(diǎn)：

(1) 硬件平臺(tái)和操作系統(tǒng)提供設(shè)置斷點(diǎn)的方法。

(2) 斷點(diǎn)觸發(fā)系統(tǒng)中斷通知到調(diào)試器的功能。

對(duì)于第一點(diǎn)斷點(diǎn)的實(shí)現(xiàn)，從計(jì)算機(jī)體系角度看分為軟件斷點(diǎn)和硬件斷點(diǎn)。軟件斷點(diǎn)是指向指定的代碼位置插入專用的斷點(diǎn)指令實(shí)現(xiàn)（插樁）。而硬件斷點(diǎn)則是通過直接利用CPU核心的調(diào)試寄存器實(shí)現(xiàn)，此場(chǎng)景主要針對(duì)不允許寫入操作的ROM只讀內(nèi)存和軟件斷點(diǎn)無法處理的情況，如中斷向量表被破壞等。

圖2

不同的硬件架構(gòu)對(duì)應(yīng)斷點(diǎn)實(shí)現(xiàn)指令也不相同，如果我們的硬件處理器基于X86系列，其軟件斷點(diǎn)工作原理是調(diào)試器將代碼對(duì)應(yīng)位置的原指令的首個(gè)字節(jié)保存起來，然后寫入一條INT3指令（圖2）。因?yàn)镮NT3指令的二進(jìn)制碼為11001100b（0xCC），僅有一個(gè)字節(jié)，所以設(shè)置和取消斷點(diǎn)時(shí)也只需要保存和恢復(fù)一個(gè)字節(jié)。

當(dāng)CPU執(zhí)行到INT3指令時(shí)，將會(huì)觸操作系統(tǒng)軟中斷并停止運(yùn)行當(dāng)前進(jìn)程，轉(zhuǎn)而執(zhí)行內(nèi)核定義好的中斷處理函數(shù)。X86的硬件斷點(diǎn)使用DR0-DR7調(diào)試地址寄存器，但是由于存儲(chǔ)斷點(diǎn)地址的寄存器數(shù)量有限（DR0-DR3），只能設(shè)置4個(gè)斷點(diǎn)。基于ARM系列的斷點(diǎn)實(shí)現(xiàn)與X86平臺(tái)類似, 軟件斷點(diǎn)的工作原理是用HLT或BRK指令的操作碼進(jìn)行指令替換，硬件斷點(diǎn)使用內(nèi)置在core中的比較器，并在執(zhí)行到達(dá)指定地址時(shí)停止執(zhí)行并觸發(fā)相應(yīng)中斷，和X86一樣，由于只提供有限數(shù)量的硬件斷點(diǎn)單元也存在斷點(diǎn)設(shè)置數(shù)量限制。

對(duì)于第二點(diǎn)操作系統(tǒng)的中斷通知，以X86平臺(tái)為例，Windows平臺(tái)由操作系統(tǒng)軟中斷觸發(fā)的對(duì)應(yīng)函數(shù)為KiTrap03()，Linux平臺(tái)則是do_int3()函數(shù)，這些函數(shù)均為操作系統(tǒng)內(nèi)核預(yù)先定義好的中斷處理例程。KiTrap03()會(huì)將斷點(diǎn)異常通過調(diào)試子系統(tǒng)以調(diào)試事件的形式分發(fā)給用戶模式的調(diào)試器，并等待調(diào)試器的回復(fù)，只有調(diào)試器確認(rèn)該異常為“自己”設(shè)置的斷點(diǎn)后，才會(huì)允許掛起被調(diào)試進(jìn)程進(jìn)行交互性調(diào)試。do_int3()例程則是向被調(diào)試進(jìn)程發(fā)送一個(gè)SIGTRAP信號(hào)，當(dāng)進(jìn)程接收到SIGTRAP信號(hào)后，當(dāng)前進(jìn)程讓出CPU暫停運(yùn)行。

3

調(diào)試原理-進(jìn)程交互模型

調(diào)試器和被調(diào)試進(jìn)程的如果都位于同一臺(tái)物理機(jī)，即為跨進(jìn)程調(diào)試，反之為遠(yuǎn)程調(diào)試，遠(yuǎn)程調(diào)試是在跨進(jìn)程調(diào)試的基礎(chǔ)上增加了一層網(wǎng)絡(luò)協(xié)議交互。由于Windows和Linux的進(jìn)程描述模型存在一定差異，我們分別介紹這兩種平臺(tái)的調(diào)試器進(jìn)程交互原理。

3.1 Windows

WIN32內(nèi)核提供了一組系統(tǒng)Api用于支持調(diào)試器與被調(diào)試進(jìn)程交互，這里挑幾個(gè)重要函數(shù)進(jìn)行介紹。

圖3

基于WIN32的調(diào)試器交互就是通過上述所示的調(diào)試函數(shù)和一系列調(diào)試事件[1]相結(jié)合實(shí)現(xiàn)。調(diào)試器啟動(dòng)后首先通過CreateProcess函數(shù)創(chuàng)建待調(diào)試進(jìn)程，或者通過調(diào)用DebugActiveProcess函數(shù)捆綁到正在運(yùn)行的進(jìn)程，在一系列準(zhǔn)備操作后就會(huì)進(jìn)入調(diào)試循環(huán)階段，調(diào)試器會(huì)阻塞調(diào)用WaitForDebugEvent函數(shù)來等待調(diào)試事件通知，當(dāng)有諸如異常事件或dll文件裝卸載事件通知到來時(shí)，此函數(shù)立即返回，返回的事件信息被封裝在DEBUG_EVENT結(jié)構(gòu)中，這個(gè)結(jié)構(gòu)包含事件的類型、相關(guān)進(jìn)程描述信息和文件句柄等。

此時(shí)調(diào)試器就進(jìn)入了命令交互階段，調(diào)試器將在自定義的事件處理函數(shù)ProcessEvent匹配事件并執(zhí)行對(duì)應(yīng)事件的回調(diào)代碼，如果是斷點(diǎn)觸發(fā)這類型操作，被調(diào)試目標(biāo)進(jìn)程的所有線程都會(huì)被操作系統(tǒng)掛起，此時(shí)調(diào)試器可以調(diào)用相關(guān)函數(shù)如GetThreadContext來獲取指定線程的上下文信息。調(diào)試器和目標(biāo)進(jìn)程地調(diào)試信息交互基于Windows進(jìn)程間同步機(jī)制，相關(guān)信息可參閱微軟相關(guān)開發(fā)文檔[2]。

圖4

3.2 Linux

相比Windows，Linux作為開源系統(tǒng)可以透過源碼更深入地窺探調(diào)試器原理，這里以GDB調(diào)試為例。

當(dāng)我們從shell終端對(duì)某個(gè)已編譯C程序文件進(jìn)行GDB命令調(diào)試時(shí)，系統(tǒng)首先會(huì)創(chuàng)建GDB進(jìn)程(調(diào)試器進(jìn)程)，該進(jìn)程會(huì)fork出一個(gè)子進(jìn)程(調(diào)試目標(biāo)進(jìn)程)，子進(jìn)程初始化后首先調(diào)用關(guān)鍵系統(tǒng)函數(shù)ptrace(PTRACE_TRACEME…)，使自身進(jìn)入被追蹤模式；同時(shí)調(diào)用execv函數(shù)執(zhí)行待調(diào)試的C程序文件，此時(shí)會(huì)暫停當(dāng)前進(jìn)程的運(yùn)行，并且發(fā)送一個(gè)SIGCHLD信號(hào)給父進(jìn)程，父進(jìn)程接收到SIGCHLD信號(hào)后就可以對(duì)被調(diào)試的進(jìn)程進(jìn)行調(diào)試。GDB也支持對(duì)已存在的進(jìn)程進(jìn)行調(diào)試，此時(shí)將由GDB進(jìn)程調(diào)用ptrace(PTRACE_ATTACH, pid, ...)對(duì)被調(diào)試進(jìn)程進(jìn)入被追蹤模式。

圖5

ptrace系統(tǒng)函數(shù)[3]是GDB交互調(diào)試的核心依賴函數(shù)，該函數(shù)的第一個(gè)參數(shù)request確定要執(zhí)行的操作模式，這些操作模式定義了調(diào)試器控制讀寫被調(diào)試進(jìn)程的行為，具體支持的操作模式如下：

圖6

借助ptrace函數(shù)的強(qiáng)大功能，GDB調(diào)試器進(jìn)程可以對(duì)調(diào)試目標(biāo)進(jìn)程的指令空間、數(shù)據(jù)空間、堆棧和寄存器的值進(jìn)行讀寫，如堆棧打印、變量展示修改等。GDB同時(shí)會(huì)截獲內(nèi)核通知到被調(diào)試進(jìn)程的幾乎所有信號(hào)，通過對(duì)這些信號(hào)的攔截和判定，調(diào)試器進(jìn)程就可以對(duì)程序進(jìn)行斷點(diǎn)匹配和單步調(diào)試等操作[4]。

4

調(diào)試器的未來發(fā)展

Windows平臺(tái)的Windbg、Linux的GDB調(diào)試器都是功能全面、具有復(fù)雜邏輯實(shí)現(xiàn)的軟件工具，這些debugger調(diào)試器因?yàn)楦灿诓煌布脚_(tái)和操作系統(tǒng)，存在著底層功能實(shí)現(xiàn)和交互模型的顯著差異，很明顯不適合跨平臺(tái)發(fā)展，而隨著Java、Js、python等解釋型語言的興起和云平臺(tái)的發(fā)展，虛擬機(jī)調(diào)試體系（JDPA、v8 debug protocol）被提出和廣泛應(yīng)用，這種百花齊放的局面讓IDE廠家面臨著一個(gè)非常棘手的問題——調(diào)試器交互規(guī)范不統(tǒng)一帶來的巨大開發(fā)難度，微軟針對(duì)此問題率先提出了DAP(Debug Adapter Protocol)協(xié)議，讓各廠家IDE（主要是還是服務(wù)自家的VsCode）通過相同的協(xié)議基于適配器模式與不同語言的debugger通信，力圖屏蔽軟硬件底層的差異性，降低IDE調(diào)試器的開發(fā)難度。DAP協(xié)議憑借著專業(yè)性和普適性得到了業(yè)界的一定認(rèn)可，不過Eclipse和IDEA等JAVA編輯器仍然是直接適配JDPA調(diào)試體系的，畢竟軟件行業(yè)統(tǒng)一規(guī)范的背后仍然是各家科技公司行業(yè)話語權(quán)的爭(zhēng)奪。

審核編輯：劉清