4. 调试脚本自动化：使用GDB脚本实现自动化测试与回归验证

手动调试，说白了就是「人肉点灯」。项目小的时候还行，一旦代码量上了十万行，每次改完Bug都要重复敲那几十条GDB命令，我反正是受不了。更别提回归验证——改一个地方，得把相关功能全跑一遍，手敲能敲到怀疑人生。

所以这一章，咱们聊聊怎么让GDB自己干活。用脚本把调试过程固化下来，一键执行，自动比对结果。这才是工程师该有的偷懒方式。

4.1 为什么需要调试脚本自动化

先看一个真实场景。我之前维护过一个电机驱动库，每次修完PWM占空比的Bug，都要手动设断点、跑波形、看寄存器、比对预期值。一套流程下来五分钟，一天改七八个地方，光重复劳动就占了大半天。

更坑的是——手滑敲错命令，或者漏看了一个寄存器的值，Bug没抓住，还得重来。

自动化能解决三个核心问题：

  • 可重复：同样的测试步骤，每次执行结果一致
  • 可追溯：脚本本身就是调试过程的文档
  • 可集成：能塞进CI/CD流水线，每次提交代码自动跑

核心观点：调试脚本不是「写一次就扔」的临时工具，它是你调试经验的固化产物。下次遇到同类问题，拿出来改两行就能用。

4.2 GDB脚本基础：从命令行到文件

GDB支持从文件读取命令。你平时在终端敲的每一条指令，都可以写进一个文本文件，然后用 -x 参数加载。

举个例子，假设有个文件 test.gdb：

# 设置断点
break main
break uart_irq_handler

# 运行程序
run

# 打印关键变量
print uart_status
print rx_buffer[0]

# 继续执行
continue

# 退出
quit

执行方式：

arm-none-eabi-gdb -x test.gdb firmware.elf

嗯，就这么简单。但光有顺序执行还不够，咱们需要更高级的能力——条件判断、循环、函数调用。

4.3 GDB内建脚本语言

GDB自己带了一套脚本语言，语法类似C的简化版。我个人习惯用它写一些「半自动化」的辅助函数。

4.3.1 定义GDB命令

用 define 关键字可以自定义命令：

define check_uart
    if $argc != 1
        echo "用法: check_uart <expected_status>\n"
    else
        set $status = *(volatile unsigned int*)0x40004400
        if $status == $arg0
            printf "UART状态正确: 0x%x\n", $status
        else
            printf "UART状态错误! 期望 0x%x, 实际 0x%x\n", $arg0, $status
        end
    end
end

然后在脚本里直接调用：

check_uart 0x03

4.3.2 循环与条件

我曾经写过一个脚本，用来遍历环形缓冲区的所有元素，检查有没有异常数据：

set $i = 0
while $i < 64
    set $val = *(unsigned char*)($ring_base + $i)
    if $val > 0x7F
        printf "异常数据: index=%d, value=0x%x\n", $i, $val
    end
    set $i = $i + 1
end

小技巧：GDB脚本里的变量名前面要加 $，不然它当成C语言符号去解析，会报错。

4.4 自动化测试框架：用Python扩展GDB

说实话，GDB内建脚本写复杂逻辑挺痛苦的。没有字符串处理，没有文件IO，连个像样的数据结构都没有。所以从GDB 7.0开始，官方推荐用Python写扩展。

Python脚本能做更多事：解析测试用例、生成报告、发邮件通知。我现在的项目基本都走Python这条路。

4.4.1 基本结构

一个典型的Python GDB脚本长这样：

import gdb

class TestUartTx(gdb.Command):
    """测试UART发送功能"""

    def __init__(self):
        super().__init__("test_uart_tx", gdb.COMMAND_USER)

    def invoke(self, arg, from_tty):
        # 设置断点
        gdb.execute("break uart_send_byte")
        gdb.execute("run")

        # 检查参数
        frame = gdb.selected_frame()
        byte_val = frame.read_var("data")
        print(f"发送的字节: 0x{byte_val:x}")

        # 检查硬件寄存器
        tx_reg = int(gdb.parse_and_eval("*(unsigned int*)0x40004404"))
        if tx_reg & 0x80:
            print("TX缓冲区空，发送正常")
        else:
            print("TX缓冲区满，发送阻塞")

        gdb.execute("continue")

TestUartTx()

加载方式：

arm-none-eabi-gdb -x test_uart.py firmware.elf

然后在GDB里直接敲 test_uart_tx 就能跑。

4.4.2 回归验证实战

回归验证的核心逻辑很简单：跑一遍测试，把结果和预期值比对。不一致就报错。

我做过一个ADC驱动回归测试脚本，结构大概是：

步骤 操作 预期结果 检查方式
1 初始化ADC 状态寄存器 == 0x01 读取0x40012000
2 启动转换 转换完成标志置位 轮询0x40012004
3 读取结果 数值在0~4095之间 检查数据寄存器
4 连续采样10次 无溢出错误 检查溢出标志

Python脚本里用 gdb.parse_and_eval() 读寄存器，用 assert 做比对：

def check_adc_reg(addr, expected, name):
    val = int(gdb.parse_and_eval(f"*(unsigned int*){addr}"))
    if val != expected:
        print(f"[FAIL] {name}: 期望 0x{expected:x}, 实际 0x{val:x}")
        return False
    else:
        print(f"[PASS] {name}: 0x{val:x}")
        return True

注意：嵌入式环境里，寄存器地址是固定的。但不同芯片外设基地址不同，脚本里最好用宏定义或者配置文件管理地址，别硬编码。

4.5 脚本化调试的完整流程

下面这张图展示了从编写脚本到回归验证的完整链路：

GDB脚本自动化调试与回归验证流程 编写GDB脚本 加载并执行脚本 自动检查结果 比对预期值 生成测试报告 ✅ 回归通过 ❌ 回归失败，定位Bug 脚本可以集成到Makefile或CI流水线中，每次编译后自动执行回归测试

4.6 集成到构建系统

脚本写好了，怎么让它每次编译完自动跑？我一般把它挂在Makefile里：

# Makefile片段
REGRESSION_SCRIPT = scripts/regression_test.py
ELF_FILE = build/firmware.elf

regression: $(ELF_FILE)
    @echo "运行回归测试..."
    arm-none-eabi-gdb -batch -x $(REGRESSION_SCRIPT) $(ELF_FILE)
    @echo "回归测试完成"

.PHONY: regression

-batch 参数让GDB跑完自动退出，适合非交互场景。配合CI工具（Jenkins、GitLab CI），每次提交代码自动触发回归。

经验之谈：回归脚本里最好加一个「总结果」变量。所有测试用例跑完后，根据这个变量决定返回0还是非0。CI工具就靠退出码判断构建是否通过。

4.7 避坑指南

做脚本自动化这几年，踩过不少坑。挑几个典型的说说：

  • 硬件状态依赖：有些测试依赖外设的初始状态。脚本开头最好加一段复位逻辑，或者检查关键寄存器，避免上次运行残留状态影响结果。
  • 超时处理：轮询等待硬件标志位时，一定要加超时。我曾经有个脚本在等待DMA传输完成时死循环了，因为DMA根本没启动。加个 $timeout 变量，超时了就报错退出。
  • 日志输出：别只打印到终端。把 gdb.execute("set logging on") 打开，所有输出写进文件，方便事后排查。
  • 脚本版本管理：调试脚本和源代码一起进Git。我见过有人把脚本放桌面，代码改了脚本没更新，回归跑了个寂寞。

曾经踩过的坑：有一次我写了个脚本，用 gdb.execute("continue") 让程序跑起来，然后等着断点触发。结果程序跑飞了，断点根本没命中，脚本一直卡在那。后来我改成用 gdb.events.stop.connect() 注册事件回调，配合超时机制，才彻底解决。

4.8 小结

调试脚本自动化，说白了就是把你的调试经验写成代码。GDB内建脚本适合简单场景，Python扩展适合复杂逻辑。配上回归验证和CI集成，能省下大量重复劳动。

我个人建议：从最简单的 -x 脚本开始，慢慢加Python扩展。别一上来就想搞个大而全的框架，先解决眼前最痛的那个重复劳动点。

← 上一章 📖 返回目录 下一章 →