原來 gdb 的底層調試原理這麼簡單

 前言  

這篇文章我們來聊聊大名鼎鼎的 GDB，它的豪門背景咱就不提了，和它的兄弟 GCC 一樣是含着金鑰匙出生的。相信每位嵌入式開發工程師都使用過 gdb 來調試程序，如果你說沒有用過，那隻能說明你的開發經歷還不夠坎坷，還需要繼續被 BUG 吊打。

我們都知道，在使用 GCC 編譯時，可以增加 -g 選項在可執行文件中嵌入更多的調試信息，那麼具體嵌入了哪些調試信息呢？這些調試信息是如何與二進制的指令之間進行相互交互的呢？在調試的時候，調試信息中是如何獲取函數調用棧中的上下文信息的呢？

針對上面這些疑惑，道哥用兩篇文章把這些底層最深處的問題徹底描述清楚，讓你一次看過癮。

第一篇文章，就是當前這一篇，主要內容是介紹 GDB 的底層調試原理，我們來看一下 GDB 是通過什麼機制來控制指令集的執行。

第二篇文章，我們選擇一個體積小巧、五臟俱全的 LUA 語言來進行剖析，從源代碼分析到函數調用棧，從指令集到調試庫的修改，一網打盡。

內容比較多，看完本文需要的時間可能長一些，爲了您的健康，不建議在處於蹲姿的時候閱讀這篇文章。

 GDB 調試模型  

GDB 調試包括 2 個程序：gdb 程序和被調試程序。根據這 2 個程序是否運行在同一臺電腦中，可以把 GDB 的調試模型分爲 2 種：本地調試和遠程調試。

本地調試：調試程序和被調試程序運行在同一臺電腦中。

遠程調試：調試程序運行在一臺電腦中，被調試程序運行在另一臺電腦中。

關於可視化調試程序並不是重點，它只是一個用來封裝 GDB 的外殼而已。我們既可以使用黑乎乎的終端窗口來調試程序；也可以使用集成開發環境 (IDE)，這個 IDE 中已經嵌入了調試器，這樣就可以單擊各種 button 來代替手動輸入調試命令了。

與本地調試相比，遠程調試中多了 GdbServer，它和目標程序都是運行在目標機中，可能是一臺 x86 電腦或者是一個 ARM 板子。圖中的紅線表示 GDB 與 GdbServer 之間通過網絡或者串口進行通訊。既然是通訊，那麼肯定需要一套通訊協議：RSP 協議，全稱是：GDB Remote Serial Protocol(GDB 遠程通信協議)。

關於通訊協議的具體格式和內容，我們不需要關心，只需要知道：它們都是字符串，有固定的開始字符 ('$') 和結束字符('#')，最後還有兩個十六進制的 ASCII 字符作爲校驗和，瞭解這麼多就足夠了。至於更多的細節，如果實在閒的 XX 可以瞄幾眼，其實這些協議，就像社會中各種奇葩的規定一樣，都是一幫磚家在廁所裏想出來的。

在第二篇講解 LUA 的文章中，我們會實現一個類似的遠程調試原型。其中的通信協議也是字符串，直接把 HTTP 協議進行簡化之後就拿過來使用了，十分清晰、方便。

 GDB 調試指令  

爲了完整性，這裏把部分 GDB 調試指令貼一下，有感性認識即可。這裏沒有列舉所有的指令，列出的指令都是常用的，比較容易理解。在講解 LUA 的時候，我們會選擇其中的某些指令進行詳細的對比，包括底層的實現機制。

每一條具體的調試指令，使用的參數還有很多，例如斷點相關的就包括：設置斷點、刪除斷點、條件斷點、臨時停用啓用等等。這篇文章的重點是理解 gdb 底層的調試機制，所以應用層的這些指令的使用方法就不再列出了，網絡上的資源很多。

 GDB 與被調試程序之間的關係  

爲了方便描述，先寫一個最最簡單的 C 程序：

編譯命令: $ gcc -g test.c -o test

我們對可執行程序 test 進行調試，輸入命令：$ gdb ./test，輸出如下：

在最後一行可以看到光標在閃爍，這是 gdb 程序在等着我們給他下達調試命令呢。當上面這個黑乎乎的終端窗口在執行 gdb ./test 的時候，在操作系統裏發生了很多複雜的事情。

操作系統首先會啓動 gdb 進程，這個進程會調用系統函數 fork()，創建一個子進程，這個子進程做兩件事情：

(1) 調用系統函數 ptrace(PTRACE_TRACEME，[其他參數])；

(2) 通過 execc 來加載、執行可執行程序 test，那麼 test 程序就在這個子進程中開始執行了。

補充一點：文中有時稱之程序，有時稱之進程。“程序” 描述的是一個靜態的概念，就是一堆數據躺着硬盤上，而 “進程” 描述的是動態的過程，是這個程序被讀取、加載到內存上之後，在操作系統中有一個任務控制塊 (一個數據結構)，專門用來管理這個進程的。

鋪墊了半天，終於輪到主角登場了，那就是系統調用函數 ptrace（其中的參數後面會解釋），正是在它的幫助下，gdb 才擁有了強大的調試能力。函數原型是：

我們先來看一下 man 中對這個函數的簡介：

tracer 就是調試程序，可以理解爲 gdb 程序；tracee 就是被調試程序，對應於圖中的目標程序 test。老外一般喜歡用 - er 和 - ee 來表示主動和被動的關係，例如：employer 就是僱主 (老闆)，employee 就是苦逼的被僱傭者 (打工人)。

ptrace 系統函數是 Linux 內核提供的一個用於進程跟蹤的系統調用，通過它，一個進程 (gdb) 可以讀寫另外一個進程 (test) 的指令空間、數據空間、堆棧和寄存器的值。而且 gdb 進程接管了 test 進程的所有信號，也就是說系統向 test 進程發送的所有信號，都被 gdb 進程接收到，這樣一來，test 進程的執行就被 gdb 控制了，從而達到調試的目的。

相當於這樣一種情況：如果沒有 gdb 調試，操作系統與目標進程之間是直接交互的；如果用 gdb 來調試程序，那麼操作系統發送給目標進程的信號就會被 gdb 截獲，gdb 根據信號的屬性來決定：在繼續運行目標程序時是否把當前截獲的信號轉交給 test，被調試程序 test 就在 gdb 發來的信號指揮下進行相應的動作。

 GDB 如何調試已經執行的服務進程

是否有小夥伴會提出這樣一個疑問：上面被調試的程序 test 是從頭開始執行的，是否可以用 gdb 來調試一個已經處於執行中的服務進程呢？答曰：可以。這就涉及到 ptrace 系統函數的第一個參數了，這個參數是一個枚舉類型的值，其中重要的是 2 個：PTRACE_TRACEME，PTRACE_ATTACH。

在上面的講解中，子進程在調用 ptrace 系統函數時使用的參數是 PTRACE_TRACEME，注意橙色文字：是子進程調用 ptrace，相當於子進程對操作系統說：gdb 進程是我的爸爸，以後你有任何想發給我的信號，請直接發給 gdb 進程吧！

如果想對一個已經執行的進程 B 進行調試，那麼就要在 gdb 這個父進程中調用 ptrace(PTRACE_ATTACH, [其他參數])，此時，gdb 進程會 attach(綁定) 到已經執行的進程 B，gdb 把進程 B 收養成爲自己的子進程，而子進程 B 的行爲等同於它進行了一次 PTRACE_TRACEME 操作。此時，gdb 進程會發送 SIGSTOP 信號給子進程 B，子進程 B 接收到 SIGSTOP 信號後，就會暫停執行進入 TASK_STOPED 狀態，表示自己準備好被調試了。

所以，不論是調試一個新程序，還是調試一個已經執行的服務程序，通過 ptrace 系統調用，最終的結果都是：gdb 程序是父進程，被調試程序是子進程，子進程的所有信號都被父進程 gdb 來接管，並且父進程 gdb 可查看、修改子進程的內部信息，包括：堆棧、寄存器等。

關於綁定，有幾個限制需要了解一下：不予許自我綁定，不允許多次綁定到同一個進程，不允許綁定 1 號進程。

 偷窺 GDB 如何實現斷點指令  

大道理已經講完了，這裏我們通過設置斷點 (break) 這個調試指令，來偷窺一下 gdb 內部的調試機制。

還是以上面的代碼爲例子，這裏再重新貼一下代碼：

來看一下編譯出來的反彙編代碼是什麼樣的 (編譯指令：gcc -S test.c; cat test.S)

這裏只貼了一部分反彙編代碼，只要能說明底層的原理就達到我們的目的了。

上面說到，在執行 gdb ./test 之後，gdb 就會 fork 出一個子進程，這個子進程首先調用 ptrace，然後執行 test 程序，這樣 gdb 就稱爲 test 的父進程了，從而可以接管 test 的所有信號。

我們把源碼和彙編代碼放在一起，方便理解：

現在我們輸入調試指令：在調試窗口輸入設置斷點指令 “break 5” ，此時 gdb 做 2 件事情：

（1）對第 5 行源碼所對應的彙編代碼存儲到斷點鏈表中。

（2）在彙編代碼的第 10 行，插入中斷指令 INT 3，也就是說：彙編代碼中的第 10 行被替換爲 INT3。

然後，在調試窗口繼續輸入執行指令 “run”(一直執行，直到遇到斷點就暫停)，彙編代碼中的 PC 指針 (一個內部指針，指向即將執行的那行代碼) 執行到第 10 行時，發現是 INT 3 指令，於是操作系統就發送一個 SIGTRAP 信號給 test 進程。

（此刻，第 10 行彙編代碼 INT3 就被執行過了，PC 指針就指向第 11 行了。）

上面已經說過，操作系統發給 test 的任何信號，都被 gdb 接管了，也就是說 gdb 會首先接收到這個信號。gdb 發現當前彙編代碼執行的是第 10 行，於是到斷點鏈表中查找，發現有第 10 行的代碼，說明第 10 行被設置了斷點，此刻 gdb 又做了 3 個操作：

（1）把彙編代碼中的第 10 行 INT3 替換爲斷點鏈表中原來的代碼。

（2）把 PC 指針回退一步，也即是設置爲指向第 10 行。

（3）繼續等待用戶的調試指令。

此刻 test 程序就暫停下來了，PC 指針指向第 10 行，也就是源碼中的第 5 行。從我們調試者角度看，就是被調試程序在第 5 行斷點處暫停了下來，我們可以繼續輸入其他調試指令來 debug，比如：查看變量值、查看堆棧信息、修改局部變量的值等等。

 偷窺 GDB 如何實現單步指令 next  

還是以剛纔的源代碼和彙編代碼爲例，假設此時程序停止在源碼的第 6 行，即彙編代碼的第 11 行：

在調試窗口輸入單步執行指令 “next”，我們的目的是執行一行代碼，也就是把源碼中第 6 行代碼執行完，然後停止在第 7 行。gdb 在接收到 “next” 執行時，會計算出第 7 行源碼，應該對應到彙編代碼的第 14 行，於是 gdb 就控制彙編代碼中的 PC 指針一直執行到第 13 行結束，也就是 PC 指向第 14 行時，就停止下來，然後繼續等待用戶輸入調試指令。

 總結  

通過 break 和 next 這 2 個調試指令，我們已經明白了 gdb 中是如何處理調試指令的了。當然，gdb 中的調試指令還有很多，包括更復雜的獲取堆棧信息、修改變量的值等等，有興趣的小夥伴可以繼續深入跟蹤。

後面我在寫 LUA 語言中的調試庫時，會更深入、詳細的討論這個問題，畢竟 LUA 語言更小巧、簡單。我也會把 LUA 代碼中如何設置 PC 指針的代碼部分給小夥伴演示一下，這樣我們對於一門編程語言的內部實現就會有更好的理解和掌握，也有可能錄一個視頻，這樣就能更好的講解 LUA 語言中的內部細節。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CfCSLpuOw5PXECB2gd4J6Q