1.概述做嵌入式開發時，很多時候都會使用到GDB，從底層去理解GDB的調試過程，將更加容易的理解調試的過程。

在做嵌入式開發調試時，可理解為兩個部分

嵌入式系統平臺，啟動一個debug stub

宿主機，啟動gdb

兩個平臺之間通過串行數據總線連接起來。

2.GDB Server的作用當PC機啟動GDB時，需要和GDB Server建立一定的通信連接，由GDB Server解析具體的邏輯并執行。

所以GDB Server可以是一個openocd，或者JTAG等等實際的外設模塊，和目標板子進行連接后，可以調試芯片。它本質上是一個解析GDB協議的模塊，或者是一段后臺的程序。

相應GDB的請求

當gdb和嵌入式平臺進行通信的時候，會發一系列的請求，例如：

讀寫內存

讀寫寄存器

設置或者清除斷點

提供調試Trap

GDB斷點的Trap

無效指令的Trap

系統錯誤的Trap

同步傳輸CPU的狀態和到遠程的GDB中。

3.一個標準的gdb的調試過程一般的正常使用編譯工具鏈中都會有gdb的工具，就拿riscv的來說，用riscv-nuclei-elf-gdb.exe去連接qemu上的gdb stub時，采用的是tcp協議。

當qemu去啟動gdb server的時候。

qemu-system-riscv32.exe -M gd32vf103v_rvstar -cpu -nographic -s -S

后面的-s表示啟動gdb server。而-S則表示綁定在TCP端口的1234端口號上。

從操作上是這個流程，那么底層的數據傳送又是怎樣的流程呢？

4.GDB 遠程串行協議解析一個標準的GDB串行協議的格式如下

$packet-data#checksum

其中的消息是通過ASCII碼進行傳輸，以$開始，以#結束。最后的checksum是命令的校驗和。

上面就是通過Wireshark監聽到的協議數據。

GDB與GDB server進行通信的時候，采用收發形式進行，必然會有下面的通信過程

發送：

$packet-data#checksum

回復

+

每次都需要回復一個+，表示收到數據。

當沒有接受到數據，或者超時時，需要進行重傳操作。

下面就是一個實際的通信過程。

gdb 和 target之間的通信一直會采用收發對稱的數據格式

比如寫內存

gdb會調用set 0x4015cc = 0xc320。

那么gdb底層的通信是

$M4015CC，2:C320#6d

目標機收到數據后，會首先返回

+

接著返回狀態

$OK#9a

這樣，一個通過gdb操作內存的中的數據的通信協議就完成了。

由于GDB的指令非常多，這里就不列舉了，但是基本的原理和格式都差別不大。

比如單步調試的指令

step：

［gdb］ $s#73

向下執行的指令

Continue

［gdb］ $c#63

控制臺輸出

Console Output

［target］ $o48656c6c6f2c20776f726c64210a#55

這樣可以在gdb控制臺上輸出hello，world！的命令。

關于命令的格式可以查看官方文檔

https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html

但是舉出一些基本的規律

5.小結用采用GDB進行調試的過程，底層的傳輸原理，采用的是非常簡單的字符串的格式，這GDB將這些命令發給硬件調試器或者板子，通過將這些命令解析后，執行具體的邏輯，就可以正常的控制芯片中程序的行為了。這就是GDB的串行協議原理。

編輯：jq