一、Bug和Debug

說起“Debug”，就不得不提及“Bug”這個程序猿和游戲玩家耳熟能詳的詞，它由美國格蕾絲·赫柏博士第一次提出，當時運行研究數據的Harvard Mark II計算機突然不能正常工作，經赫柏和團隊的反復排查，發現是一只飛蛾飛入了電腦的內部繼電器中造成短路而引起的故障。修復故障后，赫柏在日記中詼諧地記錄下了這件事（圖1）， “Bug”一詞（原意為“蟲子”）也逐漸被廣泛用于形容計算機程序中隱藏的錯誤，同時，受到從電腦中驅除飛蛾蟲子的啟發，計算機術語“Debug”（調試排錯）開始使用。

圖1

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

二、調試原理-斷點

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

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

(2) 斷點觸發系統中斷通知到調試器的功能。

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

圖2

不同的硬件架構對應斷點實現指令也不相同，如果我們的硬件處理器基于X86系列，其軟件斷點工作原理是調試器將代碼對應位置的原指令的首個字節保存起來，然后寫入一條INT3指令（圖2）。因為INT3指令的二進制碼為11001100b（0xCC），僅有一個字節，所以設置和取消斷點時也只需要保存和恢復一個字節。當CPU執行到INT3指令時，將會觸操作系統軟中斷并停止運行當前進程，轉而執行內核定義好的中斷處理函數。X86的硬件斷點使用DR0-DR7調試地址寄存器，但是由于存儲斷點地址的寄存器數量有限（DR0-DR3），只能設置4個斷點。基于ARM系列的斷點實現與X86平臺類似, 軟件斷點的工作原理是用HLT或BRK指令的操作碼進行指令替換，硬件斷點使用內置在core中的比較器，并在執行到達指定地址時停止執行并觸發相應中斷，和X86一樣，由于只提供有限數量的硬件斷點單元也存在斷點設置數量限制。

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

三、調試原理-進程交互模型

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

3.1 Windows

WIN32內核提供了一組系統Api用于支持調試器與被調試進程交互，這里挑幾個重要函數進行介紹。

圖3

基于WIN32的調試器交互就是通過上述所示的調試函數和一系列調試事件^[1]相結合實現。調試器啟動后首先通過CreateProcess函數創建待調試進程，或者通過調用DebugActiveProcess函數捆綁到正在運行的進程，在一系列準備操作后就會進入調試循環階段，調試器會阻塞調用WaitForDebugEvent函數來等待調試事件通知，當有諸如異常事件或dll文件裝卸載事件通知到來時，此函數立即返回，返回的事件信息被封裝在DEBUG_EVENT結構中，這個結構包含事件的類型、相關進程描述信息和文件句柄等。此時調試器就進入了命令交互階段，調試器將在自定義的事件處理函數ProcessEvent匹配事件并執行對應事件的回調代碼，如果是斷點觸發這類型操作，被調試目標進程的所有線程都會被操作系統掛起，此時調試器可以調用相關函數如GetThreadContext來獲取指定線程的上下文信息。調試器和目標進程地調試信息交互基于Windows進程間同步機制，相關信息可參閱微軟相關開發文檔^[2]。

圖4

3.2 Linux

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

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

圖5

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

圖6

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

4、調試器的未來發展

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