一、前言
這篇文章來聊聊大名鼎鼎的GDB，它的豪門背景咱就不提了，和它的兄弟GCC一樣是含着金鑰匙出生的，在GNU的家族中的地位不可撼動。相信每位嵌入式開發工程師都使用過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程序：
#include <stdio.h>
int main(int argc, char *argv[])
{
int a = 1;
int b = 2;
int c = a + b;
printf("c = %d \n", c);
return 0;
}
編譯命令:
$ gcc -g test.c -o test
我們對可執行程序 test 進行調試，輸入命令：
$ gdb ./test
輸出如下：
在最后一行可以看到光標在閃爍，這是gdb程序在等着我們給它下達調試命令呢。
當上面這個黑乎乎的終端窗口在執行gdb ./test的時候，在操作系統里發生了很多復雜的事情：
系統首先會啟動gdb進程，這個進程會調用系統函數fork()來創建一個子進程，這個子進程做兩件事情：
- 調用系統函數ptrace(PTRACE_TRACEME，[其他參數])；
- 通過execc來加載、執行可執行程序test，那么test程序就在這個子進程中開始執行了。
補充一點：文中有時稱之程序，有時稱之進程。“程序”描述的是一個靜態的概念，就是一堆數據躺着硬盤上，而“進程”描述的是動態的過程，是這個程序被讀取、加載到內存上之后，在操作系統中有一個任務控制塊(一個數據結構)，專門用來管理這個進程的。
鋪墊了半天，終於輪到主角登場了，那就是系統調用函數ptrace（其中的參數后面會解釋），正是在它的幫助下，gdb才擁有了強大的調試能力。函數原型是：
#include <sys/ptrace.h>
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);
我們先來看一下 man 中對這個函數的簡介：
tracer就是調試程序，可以理解為gdb程序；tracee就是被調試程序，對應於圖中的目標程序test。老外一般喜歡用-er和-ee來表示主動和被動的關系，例如：employer就是雇主(老板)，employee就是苦逼的被雇佣者(打工人)。
ptrace系統函數是Linux內核提供的一個用於進程跟蹤的系統調用，通過它，一個進程(gdb)可以讀寫另外一個進程(test)的指令空間、數據空間、堆棧和寄存器的值。而且gdb進程接管了test進程的所有信號，也就是說系統向test進程發送的所有信號，都被gdb進程接收到，這樣一來，test進程的執行就被gdb控制了，從而達到調試的目的。
也就是說，如果沒有gdb調試，操作系統與目標進程之間是直接交互的；如果使用gdb來調試程序，那么操作系統發送給目標進程的信號就會被gdb截獲，gdb根據信號的屬性來決定：在繼續運行目標程序時是否把當前截獲的信號轉交給目標程序，如此一來，目標程序就在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進程會發送SIGSTO信號給子進程B，子進程B接收到SIGSTOP信號后，就會暫停執行進入TASK_STOPED狀態，表示自己准備好被調試了。
所以，不論是調試一個新程序，還是調試一個已經處於執行中狀態的服務程序，通過ptrace系統調用，最終的結果都是：gdb程序是父進程，被調試程序是子進程，子進程的所有信號都被父進程gdb來接管，並且父進程gdb可查看、修改子進程的內部信息，包括：堆棧、寄存器等。
關於綁定，有幾個限制需要了解一下：不予許自我綁定，不允許多次綁定到同一個進程，不允許綁定1號進程。
六、偷窺GDB如何實現斷點指令
大道理已經講完了，這里我們通過設置斷點(break)這個調試指令，來偷窺一下 gdb 內部的調試機制。
還是以上面的代碼為例子，這里再重新貼一下代碼：
#include <stdio.h>
int main(int argc, char *argv[])
{
int a = 1;
int b = 2;
int c = a + b;
printf("c = %d \n", c);
return 0;
}
來看一下編譯出來的反匯編代碼是什么樣的，編譯指令：
gcc -S test.c; cat test.S)
這里只貼了一部分反匯編代碼，只要能說明底層的原理就達到我們的目的了。
上面說到，在執行gdb ./test之后，gdb就會fork出一個子進程，這個子進程首先調用ptrace然后執test程序，這樣就准備好調試環境了。
我們把源碼和匯編代碼放在一起，方便理解：
在調試窗口輸入設置斷點指令“break 5”，此時gdb做2件事情：
- 對第5行源碼所對應的第10行匯編代碼存儲到斷點鏈表中。
- 在匯編代碼的第10行，插入中斷指令INT3，也就是說：匯編代碼中的第10行被替換為INT3。
然后，在調試窗口繼續輸入執行指令“run”(一直執行，直到遇到斷點就暫停)，匯編代碼中PC指針(一個內部指針，指向即將執行的那行代碼)執行第10行時，發現是INT3指令，於是操作系統就發送一個SIGTRAP信號給test進程。
此刻，第10行匯編代碼被執行過了，PC指針就指向第11行了。
上面已經說過，操作系統發給test的任何信號，都被gdb接管了，也就是說gdb會首先接收到這SIGTRAP個信號，gdb發現當前匯編代碼執行的是第10行，於是到斷點鏈表中查找，發現鏈表中存儲了第10行的代碼，說明第10行被設置了斷點。於是gdb又做了2個操作：
- 把匯編代碼中的第10行"INT3"替換為斷點鏈表中原來的代碼。
- 把 PC 指針回退一步，也即是設置為指向第10 行。
然后，gdb繼續等待用戶的調試指令。
此刻，就相當於下一條執行的指令是匯編代碼中的第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語言中的內部細節。
如果這篇文章能給你帶來小小的幫助，歡迎評論、轉發、分享給你的朋友。
我會持續總結嵌入式項目開發過程中的實戰經驗，相信不會讓你失望的！
