GDB串行協議概述

• 1.概述

• 2.GDB Server的作用

• 3.一個標準的gdb的調試過程

• 4.GDB 遠程串行協議解析

• 5.小結

1.概述

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

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

• 嵌入式系統平臺，啟動一個debug stub
• 宿主機，啟動gdb

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

GDB整體調試的模型如下圖所示：

2.GDB Server的作用

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

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

相應GDB的請求

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

• 讀寫內存
• 讀寫寄存器
• 設置或者清除斷點

提供調試Trap

• GDB斷點的Trap
• 無效指令的Trap
• 系統錯誤的Trap

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

3.一個標準的gdb的調試過程

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

當qemu去啟動gdb server的時候。

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

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

4.GDB 遠程串行協議解析

一個標準的GDB串行協議的格式如下

$packet-data#checksum

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

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

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

發(fā)送：

回復

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

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

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

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

比如寫內存

gdb會調用set 0x4015cc = 0xc320。

那么gdb底層的通信是

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

接著返回狀態(tài)

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

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

比如單步調試的指令

step:
[gdb] $s#73

向下執(zhí)行的指令

控制臺輸出

Console Output
[target] $o48656c6c6f2c20776f726c64210a#55

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

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

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

5.小結

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