分析主流硬件平臺和操作系統(tǒng)的軟件程序Debug原理

Labs 導(dǎo)讀

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

1

Bug和Debug

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

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

圖1

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

2

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

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

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

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

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

圖2

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

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

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

3

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

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

3.1 Windows

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

圖3

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

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

圖4

3.2 Linux

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

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

圖5

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

圖6

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

4

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

Windows平臺的Windbg、Linux的GDB調(diào)試器都是功能全面、具有復(fù)雜邏輯實現(xiàn)的軟件工具，這些debugger調(diào)試器因為根植于不同硬件平臺和操作系統(tǒng)，存在著底層功能實現(xiàn)和交互模型的顯著差異，很明顯不適合跨平臺發(fā)展，而隨著Java、Js、python等解釋型語言的興起和云平臺的發(fā)展，虛擬機調(diào)試體系（JDPA、v8 debug protocol）被提出和廣泛應(yīng)用，這種百花齊放的局面讓IDE廠家面臨著一個非常棘手的問題——調(diào)試器交互規(guī)范不統(tǒng)一帶來的巨大開發(fā)難度，微軟針對此問題率先提出了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)的爭奪。

審核編輯：劉清