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

在做嵌入式開發(fā)調(diào)試時，可理解為兩個部分

嵌入式系統(tǒng)平臺，啟動一個debug stub

宿主機，啟動gdb

兩個平臺之間通過串行數(shù)據(jù)總線連接起來。

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

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

相應(yīng)GDB的請求

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

讀寫內(nèi)存

讀寫寄存器

設(shè)置或者清除斷點

提供調(diào)試Trap

GDB斷點的Trap

無效指令的Trap

系統(tǒng)錯誤的Trap

同步傳輸CPU的狀態(tài)和到遠程的GDB中。

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

當qemu去啟動gdb server的時候。

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

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

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

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

$packet-data#checksum

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

上面就是通過Wireshark監(jiān)聽到的協(xié)議數(shù)據(jù)。

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

發(fā)送：

$packet-data#checksum

回復(fù)

+

每次都需要回復(fù)一個+，表示收到數(shù)據(jù)。

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

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

gdb 和 target之間的通信一直會采用收發(fā)對稱的數(shù)據(jù)格式

比如寫內(nèi)存

gdb會調(diào)用set 0x4015cc = 0xc320。

那么gdb底層的通信是

$M4015CC，2:C320#6d

目標機收到數(shù)據(jù)后，會首先返回

+

接著返回狀態(tài)

$OK#9a

這樣，一個通過gdb操作內(nèi)存的中的數(shù)據(jù)的通信協(xié)議就完成了。

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

比如單步調(diào)試的指令

step：

［gdb］ $s#73

向下執(zhí)行的指令

Continue

［gdb］ $c#63

控制臺輸出

Console Output

［target］ $o48656c6c6f2c20776f726c64210a#55

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

關(guān)于命令的格式可以查看官方文檔

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

但是舉出一些基本的規(guī)律

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

編輯：jq