4. GDB调试实战：从断点到Core Dump离线回溯

GDB这东西，说实话是嵌入式调试的"瑞士军刀"。我早年做单片机开发时，总觉得printf大法好，直到有一次在RTOS上遇到一个随机死机——printf一开就不死，关了必死。那叫一个崩溃。后来老老实实学GDB，才发现之前走了多少弯路。

这一章，咱们就直奔主题。不讲花哨的，只讲实战中最常用的几招。

4.1 断点与Watchpoint：让程序在关键位置"停下来"

断点不是新鲜事，但怎么用得巧，是门学问。

4.1.1 普通断点与条件断点

(gdb) break main              # 在main函数入口下断点
(gdb) break source.c:128      # 在源文件第128行下断点
(gdb) break func_name if var == 0x5A  # 条件断点，满足条件才停

我个人习惯，条件断点用得最多。比如在循环里定位异常数据，你总不能每次都手动敲continue吧？

4.1.2 Watchpoint：盯住变量的"一举一动"

Watchpoint是硬件断点的一种，专门监控内存地址的读写。我遇到过最典型的场景：一个全局变量莫名其妙被改了，代码里搜了个遍找不到谁写的。这时候Watchpoint就是救命稻草。

(gdb) watch my_global_var       # 监控变量被写
(gdb) rwatch my_global_var      # 监控变量被读
(gdb) awatch my_global_var      # 读写都监控

我曾经在一个多线程项目里，用Watchpoint抓到一个中断服务程序意外修改了任务控制块的问题。那个bug藏了两个月，Watchpoint一上，十分钟定位。

4.2 堆栈回溯：bt命令与现场分析

程序崩溃后，第一件事就是看调用栈。bt（backtrace）命令就是干这个的。

(gdb) bt
#0  hard_fault_handler () at fault.c:42
#1  0x08001234 in task_scheduler () at scheduler.c:156
#2  0x0800456a in main_loop () at main.c:89

看到这个输出，你就能知道：程序是从main_loop -> task_scheduler -> hard_fault_handler一路掉下来的。问题大概率出在hard_fault_handler里，或者它调用的函数。

但有时候bt输出是乱的，比如栈被踩坏了。这时候就要看寄存器。

4.3 info registers：读懂CPU的"最后遗言"

程序崩溃时，CPU寄存器的值就是现场证据。

(gdb) info registers
r0             0x00000000       0
r1             0x2000abcd       536871885
r2             0xdeadbeef       -559038737
sp             0x2000ff00       0x2000ff00
lr             0x08001234       0x08001234
pc             0x08005678       0x08005678

怎么看？我一般按这个顺序：

1. PC（程序计数器）：崩溃时CPU正在执行哪条指令
2. LR（链接寄存器）：返回地址，告诉你谁调了当前函数
3. SP（栈指针）：栈顶位置，配合x命令看栈内容
4. R0-R3：函数参数，有时候能看出传了什么奇怪的值

4.4 x/10x $sp：手动"扒开"栈内存

有时候bt和寄存器还不够，得直接看栈里的数据。

(gdb) x/10x $sp
0x2000ff00:     0x08001234      0x2000abcd      0x00000000      0xdeadbeef
0x2000ff10:     0x0800456a      0x08007890      0x2000ffa0      0x00000001

这个命令的意思是：从SP指向的地址开始，以十六进制格式显示10个字（word，4字节）。

栈里通常保存着：局部变量、函数返回地址、保存的寄存器值。如果你熟悉编译器的栈帧布局，就能从这些数据里还原出调用关系。

4.5 Core Dump分析与离线回溯

现场调试当然好，但很多时候设备已经复位了，或者客户现场没法连调试器。这时候Core Dump就是唯一的线索。

4.5.1 什么是Core Dump

说白了，就是把CPU寄存器、栈内存、全局变量等关键数据，在崩溃瞬间保存下来。可以保存到Flash、SD卡，或者通过串口打印出来。

4.5.2 离线回溯实战

假设你从设备里读出了一段Core Dump数据，怎么分析？

# 在GDB中加载Core Dump文件
(gdb) target remote | dump_parser.py core_dump.bin
(gdb) bt
#0  0x08005678 in task_handle_msg (msg=0xdeadbeef) at task.c:42
#1  0x08001234 in scheduler_run () at scheduler.c:200

或者更简单的方式——手动解析：

1. 从Core Dump里提取PC值，找到崩溃指令
2. 提取SP值，用x/命令看栈内容
3. 提取LR值，确定调用来源
4. 对照map文件或反汇编，定位到具体函数和行号

4.6 本章知识体系

下面这张图，把GDB调试的核心流程串起来了：

4.7 实战要点总结

• 断点要"准"：条件断点比普通断点高效，Watchpoint比断点精准
• 寄存器要"读"：PC、LR、SP是三大核心，R0-R3是参数线索
• 栈内容要"看"：x/命令是手动分析栈的利器，尤其当bt输出不可信时
• Core Dump要"保"：崩溃瞬间的数据是唯一现场，保存策略要提前设计好