📚 课程目录第2章 GDB高级调试技巧

GDB 高级调试技巧：断点管理、Watchpoint、Tracepoint 与远程调试

调试嵌入式系统，GDB 是绕不开的利器。但很多人只用到了它的皮毛——设个断点，跑一下，看看变量。说实话，这太浪费了。

我做了十几年嵌入式，见过太多同事在调试上花冤枉时间。其实很多问题，用对 GDB 的高级功能，几分钟就能定位。今天我就把这些年积累的实战经验掰开揉碎讲给你听。

断点管理：硬件断点 vs 软件断点

先说说断点。很多人以为断点就一种，其实不然。GDB 里断点分两大类：软件断点和硬件断点。它们的工作原理完全不同，适用场景也大相径庭。

特性	软件断点	硬件断点
实现原理	将目标指令替换为断点指令（如 ARM 的 BKPT）	利用 CPU 调试寄存器，地址匹配时触发异常
数量限制	无限制（受内存空间约束）	通常 2-8 个（取决于芯片）
适用场景	RAM 中的代码	Flash/ROM 中的代码、中断服务程序
副作用	修改内存中的指令，影响校验和	无副作用，不修改代码

软件断点是 GDB 默认使用的。它的原理很简单：GDB 把你设断点的那条指令，替换成一条断点指令（比如 ARM 架构下的 BKPT）。CPU 执行到这条指令时，就会触发异常，GDB 接管控制权。

听起来很完美对吧？但有个坑——它只能用在 RAM 里。为什么？因为 Flash 和 ROM 是只读的，你没法往里面写指令。我曾经有个项目，代码跑在 Flash 里，设了断点死活不触发，查了半天才发现是这个问题。

注意：软件断点会修改内存中的代码。如果你的代码有 CRC 校验或校验和检查，软件断点会导致校验失败。我在一个安全关键系统里就踩过这个坑，调试时 CRC 一直报错，排查了两天才发现是断点改写了代码。

硬件断点就不一样了。它利用 CPU 内部的调试寄存器，设置一个地址匹配条件。CPU 执行到该地址时，硬件自动触发断点。整个过程不修改任何代码，所以 Flash、ROM、甚至中断向量表里的代码都能设断点。

但硬件断点有个硬伤——数量有限。ARM Cortex-M 系列通常只有 2-6 个硬件断点寄存器。我习惯把硬件断点留给那些最关键的、在 Flash 里的函数入口，软件断点则用在 RAM 里的临时调试代码上。

我的习惯：用 hbreak 命令显式设置硬件断点。GDB 默认用软件断点，但你可以通过 set breakpoint condition-evaluation target 让 GDB 自动选择。不过我个人更喜欢手动控制，心里有数。

Watchpoint：数据变化的哨兵

断点监视的是代码执行流，但很多时候我们需要监视数据的变化。比如一个全局变量被谁改了？一个指针什么时候变成了 NULL？这时候 Watchpoint 就派上用场了。

Watchpoint 本质上是一种特殊的硬件断点，它监视的是内存地址的读写操作。GDB 支持三种 Watchpoint：

普通 Watchpoint（watch）：监视变量被写入时触发
读 Watchpoint（rwatch）：监视变量被读取时触发
读写 Watchpoint（awatch）：监视变量被读取或写入时触发

用法很简单：

(gdb) watch my_variable          # 监视写入
(gdb) rwatch my_variable         # 监视读取
(gdb) awatch my_variable         # 监视读写
(gdb) info watchpoints           # 查看所有 Watchpoint
(gdb) delete 3                   # 删除编号为 3 的 Watchpoint

我遇到过最典型的场景：一个全局结构体被多个任务访问，偶尔出现数据错乱。用 Watchpoint 监视结构体的关键字段，谁改的立刻就能抓到。有一次调试一个 CAN 通信协议栈，数据帧的 ID 字段总被莫名其妙修改，用 Watchpoint 一抓，发现是一个中断服务程序里不小心用了同一个缓冲区。

注意：Watchpoint 依赖硬件调试寄存器，数量非常有限（通常 1-4 个）。而且监视大数组或结构体时，CPU 需要逐字节比较，性能开销很大。我建议只监视关键字段，不要监视整个结构体。

Tracepoint：无侵入的调试利器

有些 Bug 很狡猾——只在特定时序下出现，你一设断点，时序变了，Bug 就消失了。这就是所谓的「Heisenbug」。Tracepoint 就是为这种情况设计的。

Tracepoint 不会暂停程序执行，它只是在指定位置记录数据，然后继续运行。GDB 会把记录的数据保存下来，调试结束后再分析。这就像给程序装了一个「黑匣子」。

设置 Tracepoint 的步骤：

用 trace 命令设置 Tracepoint
用 actions 命令定义要记录的数据
用 tstart 启动跟踪
运行程序
用 tstop 停止跟踪
用 tfind 查看记录的数据

举个例子：

(gdb) trace my_function
(gdb) actions
> collect my_var
> collect $regs
> end
(gdb) tstart
(gdb) continue
... 程序运行一段时间后 ...
(gdb) tstop
(gdb) tfind start
(gdb) print my_var

Tracepoint 的妙处在于：它可以在 Flash 里工作，而且几乎不改变程序的行为。我曾经用它调试一个电机控制算法，那个 Bug 只在 PWM 频率达到 20kHz 时才出现，用断点根本抓不到。Tracepoint 记录了几个关键变量的变化曲线，一分析就发现是某个滤波系数溢出导致的。

小技巧：Tracepoint 记录的数据可以导出成文件，用 Python 或 MATLAB 做离线分析。我经常把数据导出来画波形图，比在 GDB 里看数字直观多了。

Core Dump 分析：事后诸葛亮也是诸葛亮

现场调试当然好，但很多时候我们拿不到现场——产品已经交付给客户了，崩溃了只能寄回来一个日志文件。这时候 Core Dump 就是救命稻草。

Core Dump 是程序崩溃时内存的快照。GDB 可以加载这个快照，像调试活进程一样分析崩溃时的状态。关键是：编译时一定要加 -g 选项，否则你看到的全是地址，没有符号信息。

分析 Core Dump 的基本流程：

$ gdb my_program core.12345
(gdb) bt                    # 查看调用栈
(gdb) info registers        # 查看寄存器状态
(gdb) frame 2               # 切换到第 2 层栈帧
(gdb) print local_var       # 查看局部变量
(gdb) list                  # 查看源代码

我遇到过最经典的案例：一个嵌入式设备在野外运行了三个月后死机，客户把 Core Dump 发回来。加载后一看调用栈，发现是一个消息队列满了，发送任务在等待时被高优先级任务抢占，导致死锁。如果没这个 Core Dump，根本不可能复现。

  关键配置：嵌入式 Linux 系统要开启 Core Dump 功能：

  ulimit -c unlimited  # 取消 Core Dump 大小限制

  echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern  # 设置 Core Dump 文件名格式

远程调试：本地 IDE，远程板子

嵌入式开发最常见的场景：你的开发电脑是 x86，目标板是 ARM。怎么调试？远程调试。

GDB 远程调试的架构很简单：目标板上运行一个 GDB Server（如 gdbserver、OpenOCD、J-Link GDB Server），开发电脑上运行 GDB Client，两者通过网络或 JTAG 通信。

基本步骤：

目标板上启动 GDB Server：gdbserver :1234 my_program
开发电脑上启动 GDB Client：arm-none-eabi-gdb my_program
在 GDB 中连接目标板：target remote 192.168.1.100:1234
开始调试：break main → continue

远程调试的坑也不少。我总结几个常见问题：

网络延迟：Wi-Fi 调试经常断，建议用有线网络
符号文件不匹配：目标板上的可执行文件必须和开发电脑上的完全一致，包括编译时间戳
Flash 下载：有些 GDB Server 不支持 Flash 下载，需要先用烧录工具把程序烧进去
中断响应：远程调试时，断点触发会导致中断延迟，影响实时性

我的经验：调试实时性要求高的系统时，我会用硬件断点 + 条件断点组合，尽量减少暂停次数。或者用 Tracepoint 做无侵入调试，等程序跑完再分析数据。

知识体系总览

下面这张图把 GDB 高级调试的核心知识点串起来了。你可以把它当作调试时的「作战地图」。

调试是一门手艺，工具只是手段。GDB 的这些高级功能，说白了就是给你更多维度的视角去看程序运行时的状态。我建议你花点时间把这些命令练熟，下次遇到棘手的 Bug，就不会束手无策了。