什么是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 語言中的內部細節。