4、GDB断点管理：让程序在你想停的地方停下来

调试嵌入式程序，说白了就是让程序按照我们的意愿运行。而断点，就是我们控制程序执行节奏的「红绿灯」。这一章，我们来聊聊GDB中断点的那些事儿——怎么查看、怎么删除、怎么临时关掉，还有最实用的条件断点。

我个人习惯，调试前先把断点规划好。就像写代码前先画流程图一样，想清楚要在哪些关键路径上停下来观察。嗯，这个习惯帮我省了不少时间。

4.1 查看断点：info break

你设了一堆断点，但时间一长就忘了设在哪。这时候，info break 就是你的「断点地图」。

(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x08048450 in main at test.c:10
2       breakpoint     keep y   0x08048470 in func_a at test.c:25
3       breakpoint     keep n   0x08048490 in func_b at test.c:40

这张表里，每一列都很关键：

4.2 删除断点：delete

断点设多了，有些已经没用了。删掉它们，免得干扰调试节奏。

(gdb) delete 2          # 删除编号为2的断点
(gdb) delete 1 3 5      # 同时删除1、3、5号断点
(gdb) delete            # 删除所有断点（会提示确认）

我曾经在调试一个UART驱动时，一口气设了十几个断点。后来发现其中几个根本不会触发，用 delete 清理掉后，调试流程清晰多了。

4.3 禁用/启用断点：disable/enable

有时候，你不想删除断点，只是暂时不想让它触发。比如，某个断点所在的函数被频繁调用，每次停下来都打断你的思路。

(gdb) disable 2         # 禁用2号断点
(gdb) enable 2          # 重新启用2号断点
(gdb) disable 1 3 5     # 批量禁用
(gdb) enable 1 3 5      # 批量启用

你想想看，这就像给断点加了个「开关」。我在调试一个定时器中断服务程序时，就经常用这个功能——先禁用所有断点，让程序跑起来，等需要观察时再逐个启用。

4.4 条件断点：让断点「聪明」起来

普通断点每次执行到那一行都会停下来。但很多时候，我们只关心特定条件下的情况。比如，循环执行1000次，我们只想在第500次时停下来看看。

条件断点就是干这个的。

(gdb) break test.c:10 if count == 500
(gdb) break func_a if value > 100 && value < 200
(gdb) break 25 if strcmp(name, "error") == 0

语法很简单：在普通断点后面加 if 条件表达式。条件可以是任何合法的C表达式，支持 &&、||、==、!= 等运算符。

我曾经调试过一个网络协议栈，某个数据包在特定条件下会丢包。我在数据发送函数上设了个条件断点：break send_packet if packet_id == 0x1234。这样每次只停在我关心的那个包上，效率提升了好几倍。

4.4.1 给已有断点加条件

如果你已经设了一个普通断点，后来想给它加条件，不用删了重设：

(gdb) condition 2 count > 1000
(gdb) condition 2        # 清除2号断点的条件，变回普通断点

4.5 知识体系总览

下面这张图，帮你把断点管理的核心逻辑串起来：

4.6 实战小贴士

最后，分享几个我在项目中积累的经验：

• 断点命名： 虽然GDB不支持给断点起名字，但你可以用注释来标记。比如在代码里写 // BREAKPOINT: check buffer overflow，这样 info break 时看到行号，就能对应上。
• 断点文件： 把常用的断点保存到文件里，用 source 命令加载。我每次调试一个新板子，都会先加载一个断点配置文件，省得一个个手动设。
• 临时断点： 用 tbreak 设置一次性断点，触发一次后自动删除。适合只想停一次的场景。

嗯，断点管理就聊到这里。记住，调试不是碰运气，而是有策略地观察。把断点用好，你就能看到程序运行的每一个细节。