GDB串行协议概述

• 1.概述

• 2.GDB Server的作用

• 3.一个标准的gdb的调试过程

• 4.GDB 远程串行协议解析

• 5.小结

1.概述

做嵌入式开发时，很多时候都会使用到GDB，从底层去理解GDB的调试过程，将更加容易的理解调试的过程。

在做嵌入式开发调试时，可理解为两个部分

• 嵌入式系统平台，启动一个debug stub
• 宿主机，启动gdb

两个平台之间通过串行数据总线连接起来。

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的串行协议原理。