3. GDB 高级技巧：条件断点、观察点、回溯追踪、core dump 分析、远程调试配置

调试这事儿，说白了就是跟 bug 斗智斗勇。GDB 基础命令谁都会用，但真正能让你效率翻倍的，是那些高级技巧。我做了十几年嵌入式，踩过的坑不少，今天就把这些压箱底的东西掏出来跟你聊聊。

3.1 条件断点：让断点自己挑活儿干

普通断点有个毛病——每次执行到那行都会停。循环里跑一万次，你就得按一万次 continue，手都按酸了。条件断点就是干这个的：只有满足特定条件才触发。

(gdb) break main.c:42 if count > 1000 && flag == 1
(gdb) break func_name if strcmp(str, "error") == 0
(gdb) condition 1 count > 500   # 给断点编号1添加条件

我个人习惯在调试通信协议栈时这么用。比如收包函数里，我只想停在第 100 个异常包上，加个条件断点，喝杯咖啡回来正好命中。

3.2 观察点：数据变化的哨兵

断点管的是代码执行到哪一行，观察点管的是内存数据什么时候变。你想想看，一个全局变量莫名其妙被改了，你翻遍所有赋值语句都找不到凶手——这时候观察点就是你的福尔摩斯。

(gdb) watch my_var           # 变量被写入时触发
(gdb) watch *(int*)0x20001000 # 监控指定地址
(gdb) awatch my_array[5]      # 读写都触发（access watch）
(gdb) rwatch my_var           # 只读触发（read watch）

我曾经在调试一个 RTOS 任务栈溢出时，用观察点监控栈顶地址。程序跑着跑着，观察点突然触发，一看调用栈，好家伙，一个中断服务函数里递归调用了自己。没有观察点，这种 bug 查三天都不一定找得到。

3.3 回溯追踪：还原案发现场

程序崩溃了，你只知道当前在哪一行。但它是怎么走到这一步的？回溯追踪就是帮你把来时的路画出来。

(gdb) backtrace        # 简写 bt，打印调用栈
(gdb) bt full          # 显示每个栈帧的局部变量
(gdb) frame 2          # 切换到第2层栈帧
(gdb) info locals      # 查看当前帧的局部变量
(gdb) up / down        # 上下切换栈帧

嗯，这里要注意：嵌入式环境里，如果优化开得太高（-O2 以上），GDB 可能认不出完整的调用栈。我建议调试时用 -O0 -g 编译，等调通了再开优化。别问我怎么知道的——有一次我对着一个残缺的 backtrace 看了整整一下午，最后发现是优化把栈帧给优化掉了。

命令	作用	常用场景
bt	打印完整调用栈	崩溃后第一时间查看
bt full	显示所有局部变量	需要分析参数传递时
frame N	切换到第 N 层	查看上层调用者的状态
info args	显示当前帧参数	检查函数入参是否正确

3.4 Core Dump 分析：死后验尸

有些 bug 在调试器里跑就不出现，一脱离调试器就崩。Core dump 就是程序死的时候留下的「尸体」——内存快照、寄存器状态、调用栈全在里面。

首先得让系统生成 core dump：

# 设置 core 文件大小不限
$ ulimit -c unlimited

# 指定 core 文件路径和命名格式
$ echo "/tmp/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

然后用 GDB 分析：

$ arm-none-eabi-gdb my_program.elf /tmp/core.my_program.1234
(gdb) bt
(gdb) info registers
(gdb) x/20x $sp    # 查看栈内存
(gdb) list         # 查看崩溃位置的源代码

我记得有一次客户现场报了一个随机死机的问题，我远程连不上设备，就让现场同事把 core dump 发回来。打开一看，$pc 指向了一个野指针跳转的目标地址，再查查堆内存分配记录——发现是一个已经 free 掉的内存块被再次使用了。没有 core dump，这种偶发问题根本没法复现。

3.5 远程调试配置：隔空捉虫

嵌入式开发最头疼的就是目标板不在手边。GDB 远程调试就是你的「千里眼」——在 PC 上运行 GDB，通过网络或串口连接目标板上的 GDB Server，就能像本地调试一样操作。

目标板端（运行 GDB Server）：

# 使用 gdbserver 监听端口
$ gdbserver :2345 my_program

# 或者用 OpenOCD + JTAG
$ openocd -f interface/jlink.cfg -f target/stm32f4x.cfg

PC 端（运行 GDB Client）：

$ arm-none-eabi-gdb my_program.elf
(gdb) target remote 192.168.1.100:2345
(gdb) continue
(gdb) break main.c:100
(gdb) continue

我个人习惯在调试脚本里把连接命令写成一个宏，省得每次敲一堆：

define connect-remote
  target remote ${1}:2345
  monitor reset halt
  load
  continue
end

3.6 实战组合拳：一个真实案例

说了这么多，咱们串起来走一遍。假设你遇到一个问题：系统运行 2-3 小时后，某个传感器的数据突然变成 0xFF。

1. 先上观察点：watch sensor_data，看谁在写这个变量。
2. 触发后看回溯：bt 发现是一个定时器回调函数在写。
3. 设条件断点：break timer_callback if sensor_data == 0xFF，精准定位到异常时刻。
4. 分析上下文：info locals 发现定时器计数值溢出了，导致写入了错误数据。
5. 修复验证：改完代码，用 continue 跑一晚上，观察点再也没触发。

你看，这一套下来，从发现问题到定位根因，不到半小时。要是没有这些高级技巧，你可能还在满世界找那个「偶尔出现」的 bug。