4. 断点艺术：break命令详解、条件断点、临时断点、硬件断点、断点管理

调试嵌入式程序，说白了就是跟断点打交道。

我见过不少工程师，调试时只会一招——b main，然后一路next下去。遇到复杂bug就抓瞎了。其实GDB的断点系统远比你想的丰富。用好它，调试效率能翻倍。

4.1 break命令：最基础的武器

break（简写b）是GDB最常用的命令。用法很简单：

(gdb) b main           // 在main函数入口停
(gdb) b 42             // 在当前文件的第42行停
(gdb) b file.c:128     // 在file.c的第128行停
(gdb) b my_function    // 在my_function入口停

我个人习惯用b file.c:line这种形式。为什么？因为多文件项目里，不同文件可能有相同的行号，指定文件名能避免歧义。

4.2 条件断点：精准打击

普通断点有个问题——循环里每次都会停。比如你有个for循环跑1000次，只在第500次才出问题。手动next 500次？别傻了。

条件断点就是干这个的：

(gdb) b 42 if i == 500
(gdb) b file.c:128 if buffer != NULL
(gdb) b my_function if error_count > 3

我曾经在调试一个网络协议栈时，遇到一个只在特定数据包长度下触发的bug。用条件断点b packet_handler if len > 1500，一下子就定位到了问题。要是没有条件断点，我估计得盯着日志看一整天。

4.3 临时断点：用完即弃

有时候你只想停一次。比如某个函数只在特定路径下被调用一次，你进去看一眼就完事。这时候用tbreak（temporary break）：

(gdb) tbreak 42
(gdb) tbreak file.c:128
(gdb) tbreak my_function

临时断点触发一次后自动删除。我经常在调试启动流程时用这个——在初始化函数里设个临时断点，看一眼状态就继续跑，省得手动删断点。

4.4 硬件断点：对付Flash和只读区域

嵌入式调试有个坑——代码在Flash里跑。普通断点（软件断点）需要修改指令，把目标地址的指令替换成断点指令（比如ARM的BKPT）。但Flash是只读的，写不进去啊。

这时候就得用硬件断点。它利用CPU的调试寄存器来实现，不修改内存：

(gdb) hbreak 0x08001234   // 在Flash地址设硬件断点
(gdb) hbreak my_function  // 在函数入口设硬件断点

硬件断点数量有限。ARM Cortex-M系列通常只有4-8个。用完了？那就只能删掉不用的了。

4.5 断点管理：别让断点变成灾难

项目大了，断点一多就容易乱。我见过有人调试时设了20多个断点，最后自己都忘了哪些是干嘛的。GDB提供了完整的断点管理命令：

我个人习惯给断点加注释：

(gdb) b 42
(gdb) comment 1  // 检查buffer是否溢出

这样下次看info break时，就知道每个断点是干嘛的了。

4.6 断点的高级玩法

除了上面这些，还有几个我常用的技巧：

• 断点命令列表： 断点触发时自动执行一系列命令。比如我想在每次进入某个函数时打印参数：
  b my_function
commands
> print arg1
> print arg2
> continue
> end
• 观察点： 监控某个变量是否被修改。用watch my_var，变量值一变就停。调试野指针时特别好用。
• 捕获点： 捕获C++异常或系统调用。用catch throw捕获所有抛出的异常。

4.7 知识体系图

下面这张图总结了本章的断点体系：

嗯，断点这东西，用好了是神器，用不好就是灾难。我建议你每次调试前，先想想：我到底想观察什么？ 然后有针对性地设断点，而不是到处乱设。这样调试效率会高很多。

记住，调试不是碰运气，而是有策略的排查。断点就是你手里的手术刀，精准、锋利、可控。