3. GDB断点管理：调试的“刹车系统”
调试嵌入式程序，说白了就是让代码“慢下来”。
断点就是我们的刹车。没有它，程序一溜烟跑完了，你连它在哪出问题的都不知道。我个人习惯，在开始任何调试之前，先把关键位置的断点布好，就像下棋先布阵一样。
核心思想：断点不是越多越好，而是越精准越好。我曾经见过一个同事，一口气设了30多个断点，结果自己都忘了哪个是干嘛的。调试变成了猜谜游戏。
3.1 设置断点：break 命令
最基础的断点设置，用 break 命令，简写是 b。
(gdb) break main # 在函数 main 入口处设断点
(gdb) break 42 # 在当前文件的第42行设断点
(gdb) break file.c:100 # 在 file.c 的第100行设断点
(gdb) break func if x > 5 # 条件断点，后面会细说嗯，这里要注意：如果你有多个同名函数，GDB 会列出所有匹配项让你选。比如你写了两个 init 函数，GDB 会问你要停在哪一个。
我的习惯：调试时我更喜欢用“文件名:行号”的方式。为什么？因为嵌入式项目里，不同文件可能有相同的函数名，用行号最精确，不会搞混。
3.2 条件断点：只在需要时停下
条件断点是我在项目中用得最多的。你想想看，一个循环跑1000次，你只想知道第500次时发生了什么。如果每次都手动停，手都按酸了。
(gdb) break 42 if count == 500
(gdb) break packet_handler if packet_id == 0xFF我曾经调试一个网络协议栈，数据包一秒钟进来几百个。我只需要看特定ID的包。条件断点一设，世界清净了。GDB 只在条件满足时才触发，其他时候默默跑过。
避坑指南：条件表达式里不要写有副作用的代码。比如 if count++ == 500，这会导致 count 被多增加一次，bug 越调越多。我曾经就犯过这个错，查了整整一下午。
3.3 临时断点：用完即弃
临时断点用 tbreak 命令。它只触发一次，触发后自动删除。
(gdb) tbreak 88
(gdb) tbreak malloc什么时候用？比如你想让程序跑到某个位置，但只停这一次。我经常用它来“跳”过一段已知没问题的代码，直接停在怀疑的位置。
说白了，临时断点就是一次性的刹车片。踩完就没了，省得你手动去删。
3.4 禁用/启用断点：灵活控制
有时候你不想删断点，只是暂时不想让它生效。用 disable 和 enable。
(gdb) disable 2 # 禁用编号为2的断点
(gdb) enable 2 # 重新启用
(gdb) disable # 禁用所有断点
(gdb) enable # 启用所有断点每个断点都有一个编号。你设的第一个断点编号是1，第二个是2，以此类推。这个编号很重要，后面所有操作都靠它。
我的经验：调试复杂问题时，我会把断点分组。比如前5个断点检查初始化流程，后3个检查主循环。调试完初始化部分，直接 disable 1-5，干净利落。
3.5 删除断点：清理战场
用 delete 命令，简写 d。
(gdb) delete 2 # 删除编号为2的断点
(gdb) delete # 删除所有断点（会询问确认）
(gdb) clear main # 删除在 main 函数处的断点
(gdb) clear 42 # 删除在第42行的断点clear 和 delete 的区别：clear 按位置删，delete 按编号删。我个人更习惯用 delete，因为编号更直观。
3.6 查看断点列表：知己知彼
用 info breakpoints 或简写 i b。
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048450 main
2 breakpoint keep n 0x08048490 file.c:42
3 hw breakpoint keep y 0x080484c0 func if x > 5这张表里信息很丰富：
| 列名 | 含义 |
|---|---|
| Num | 断点编号，操作时用这个 |
| Type | 断点类型：breakpoint（软件断点）、hw breakpoint（硬件断点） |
| Disp | 触发后的行为：keep（保留）、del（临时断点，触发后删除） |
| Enb | 是否启用：y（启用）、n（禁用） |
| Address | 断点的内存地址 |
| What | 断点位置和条件 |
重要提醒：嵌入式调试中，硬件断点数量是有限的。ARM Cortex-M 系列通常只有4-8个硬件断点。软件断点则没有数量限制。如果你发现设不了断点，先看看是不是硬件断点用完了。
知识体系总览
下面这张图帮你理清断点管理的整体脉络：
实战小技巧
最后分享几个我常用的组合拳：
- 调试循环：先用
b 42 if i == 500停在特定迭代，然后用tbreak 45在循环体内设临时断点，单步观察变量变化。 - 调试中断：嵌入式里中断处理函数很关键。用
b hard_fault_handler设断点，一旦触发就是严重错误。我遇到过几次，都是指针越界导致的。 - 批量操作：用
enable 1-5或disable 6-10批量控制断点，比一个个操作快得多。
最后提醒：调试完记得清理断点。我曾经把带断点的程序烧到产品里，结果客户现场一跑就停，场面一度非常尴尬。用 delete 清干净再发布。
断点管理就这些了。说白了，就是“设、查、改、删”四个字。多练几次，形成肌肉记忆，调试效率能翻一倍。