断点是怎么“刹住”程序的？揭开嵌入式调试的底层真相
断点调试是我们填坑、定位 bug 的神器。每次在 IDE 里点下断点，看着程序乖乖停在指定位置，是不是有种掌控全局的快感？但你有没有想过，断点到底是怎么实现的？为什么有时候断点会失灵，或者硬件断点用着用着就没了？今天，我们就来聊聊断点调试的底层原理。断点的前世今生断点的概念其实可以追溯到七十多年前的 ENIAC 计算机时代。那时候调试程序可不像现在这么优雅，想暂停程序，得直接拔掉一根控制程序流的电缆，这种操作就被称为 断点。听起来是不是有点硬核？到了今天，断点已经成为嵌入式开发的标配，几乎所有芯片架构都内置了专门的指令来支持它。接下来，我们就从硬件和软件两个角度，聊聊断点的工作原理。硬件断点硬件断点是芯片自带的调试利器，核心在于芯片内部的比较器。简单来说，芯片里有一块专门的硬件模块，会实时对比当前取指的指令地址和调试器配置的断点地址。如果两者匹配，芯片就会触发一个调试事件，比如暂停 CPU 核心或者抛出异常。以 Cortex-M 系列为例，硬件断点功能主要由 Flash Patch and Breakpoint Unit（FPB） 模块提供。FPB 里有一组寄存器，叫做 FP_COMP，专门用来存断点地址。每次 CPU 取指时，FPB 会把指令地址和这些寄存器里的地址做比较，匹配上了就暂停程序。但硬件断点有个硬伤：数量有限。一般 Cortex-M 芯片只提供 2 到 6 个硬件断点，多的也不超过 127 个。这是因为比较器是硅片上实打实的硬件资源，数量由芯片设计决定。开发中如果你发现断点设多了，调试器开始报错，大概率就是硬件断点用完了。实际案例：假设你在调试一块 nRF52840 开发板，想在代码的某个函数入口设断点。你用 GDB 敲下 break dummy_function_1，调试器会通过 JLink 的 GDB Server，把断点地址写入 FPB 的 FP_COMP0 寄存器。程序运行到这个地址时，FPB 检测到匹配，CPU 立刻暂停，调试器接管控制权，完美！软件断点软件断点就显得更软一些。它的核心思路是：调试器直接修改程序代码，在你想暂停的地方插入一条特殊的断点指令（比如 ARM 的 BKPT 指令）。当 CPU 执行到这条指令时，会触发调试事件，程序暂停。软件断点的最大优势是数量几乎无限，因为它不依赖硬件资源，想设多少断点都行。但这也带来了几个挑战：
[*]只读存储器（ROM）没法改：如果你的代码跑在 Flash 里，调试器得先把 Flash 页面擦除、重写，才能插入断点指令。这操作可不简单，效率低不说，还可能磨损 Flash。
[*]调试器崩了怎么办：如果调试器意外退出，断点指令可能残留在代码里，导致程序跑飞甚至死循环。比如，BKPT 指令在没有调试器的情况下会触发 HardFault，程序直接崩。
断点实战：以 nRF52840 为例为了让大家更直观地感受断点的实现，我们以一块 nRF52840-DK 开发板为实验平台，跑一个简单的裸机程序，工具链包括：
[*]硬件：nRF52840-DK（Cortex-M4F 内核）
[*]调试器：SEGGER JLinkGDBServer
[*]编译器：GCC 9.3.1（GNU Arm Embedded Toolchain）
程序里我们实现了一个简单的命令行 shell，包含几个测试函数（dummy_function_1 到 dummy_function_9），每个函数只是打印自己的名字。我们用 GDB 来设置断点，观察硬件和软件断点的工作过程。1. 硬件断点设置假设我们想在 dummy_function_1（地址 0x240）设一个断点。执行以下 GDB 命令：(gdb) break dummy_function_1
调试器会通过 GDB Remote Serial Protocol（RSP）发送一个 Z1,240,2 包，告诉 JLinkGDBServer 在地址 0x240 设置硬件断点。JLink 会把这个地址写入 FPB 的 FP_COMP0 寄存器，并启用比较器。我们可以通过程序里的 fpb_dump 命令，查看 FPB 寄存器的状态：shell> fpb_dump
FPB Revision: 0, Enabled: 1, Hardware Breakpoints: 6
FP_COMP Enabled 1, Replace: 1, Address 0x240
FP_COMP Enabled 0, Replace: 0, Address 0x0
...
可以看到，FP_COMP0 已经配置了断点地址 0x240。当程序运行到这个地址时，FPB 触发调试事件，CPU 暂停，GDB 接管。2. 软件断点在 RAM 中的应用现在我们试试在 SRAM 里设置断点，比如 dummy_function_ram（ 地址是 0x20000000。同样用 GDB 设置断点：(gdb) break dummy_function_ram
因为 SRAM 可写，调试器会直接在 0x20000000 地址处插入 BKPT 指令（编码为 0xbe00）。我们用 dump_dummy_funcs 命令检查：shell> dump_dummy_funcs
dummy_function_ram: Starts at 0x20000000. First Instruction = 0x4802be00
可以看到，原始指令已经被替换成了 BKPT，说明软件断点成功设置。3. 用光硬件断点会怎样？nRF52840 提供 6 个硬件断点。如果我们把这 6 个都用完（比如在 dummy_function_1 到 dummy_function_6 各设一个断点），再尝试在 dummy_function_7（地址 0x2a0）设断点，会发生什么？GDB 会发送 Z0,2a0,2 包，请求设置软件断点。因为硬件断点已经用完，JLinkGDBServer 会擦除 Flash 页面，把 0x2a0 地址的指令替换为 BKPT。我们再次检查：shell> dump_dummy_funcs
dummy_function_7: Starts at 0x2a0. First Instruction = 0x4802be00
果然，BKPT 指令出现了！这说明调试器在 Flash 中插入了软件断点。4. 小心软件断点的坑软件断点虽然好用，但也有风险。比如，如果调试器异常退出，Flash 里的 BKPT 指令可能没被清理干净。重新上电后，程序运行到这个指令会触发 HardFault，导致死循环。我们可以模拟一下：
[*]拔掉开发板电源。
[*]重新上电，连接串口终端。
[*]执行 call_dummy_funcs 命令，程序直接重启：
shell> call_dummy_funcs
==Booted==
这就是 BKPT 指令残留导致的 HardFault。为了避免这种情况，调试完成后记得用 GDB 的 delete 命令清理所有断点，或者重新烧录程序。GDB 的断点魔法GDB 在设置断点时，会通过 GDB Remote Serial Protocol（RSP）与调试器通信。常见的命令包括：
[*]Z0,addr,kind：设置软件断点
[*]Z1,addr,kind：设置硬件断点
[*]z0,addr,kind：移除软件断点
[*]z1,addr,kind：移除硬件断点
有趣的是，GDB 为了避免断点重复触发，会在程序暂停时临时移除断点，单步执行后再重新设置。比如，当我们执行 continue 命令时，GDB 会：
[*]发送 z0,addr,kind 移除断点。
[*]发送 s 包进行单步执行。
[*]再发送 Z0,addr,kind 恢复断点。
这种机制既保证了调试的正确性，也降低了调试器崩掉后断点残留的风险。FPB 的隐藏技能ARM Cortex-M 的 FPB 模块除了支持硬件断点，还有个冷门功能：Flash Patch。它可以动态修改 Flash 中的代码或数据，早期常用于修补 ROM 里的 bug 或调试 Bootloader。不过现在 OTA 更新流行，这个功能用得少了。FPB 的寄存器配置也很讲究。比如，FP_CTRL 寄存器告诉你支持多少个断点，而 FP_COMP 寄存器控制具体的断点地址和行为。国内开发者在调试时，可以通过自写代码（像文中提到的 fpb_dump）来检查 FPB 状态，方便定位断点相关的问题。
页:
[1]
