3、断点原理（上）：软件断点的实现机制（int 3指令）、断点命中与恢复执行

断点这东西，每个用GDB的人天天都在用。但你真的想过，当你敲下b main的那一刻，底层到底发生了什么吗？

我个人习惯把断点分成两类：软件断点和硬件断点。今天咱们先聊软件断点，这是最基础、也是最常用的一种。说白了，它的核心就一条指令——int 3。

int 3是一条单字节指令，机器码是0xCC。为什么是单字节？因为断点需要被插入到任意指令位置，如果指令太长，替换起来会很麻烦。单字节，一个位置，干净利落。

当CPU执行到0xCC时，会触发一个中断（Interrupt 3）。操作系统捕获这个中断后，会暂停当前进程，并把控制权交给调试器。嗯，这里要注意：int 3和普通的int指令不同，它是专门为调试器设计的。

核心流程：

我曾经在调试一个嵌入式实时系统时，发现断点总是打不进去。查了半天，原来是那块芯片的Flash控制器对0xCC做了特殊处理——它把0xCC当成了一条合法指令来执行，根本没触发中断。那次之后，我养成了一个习惯：在陌生平台上先验证int 3是否真的能触发断点。

你想想看，程序跑着跑着，突然遇到0xCC，CPU就停了。但GDB怎么知道是哪个断点被触发了？

这里有个关键点：断点地址匹配。GDB内部维护了一张断点表，记录了所有活跃断点的地址。当int 3触发时，操作系统会把触发中断的指令地址（也就是断点地址）告诉GDB。GDB查一下表，就知道是哪个断点被命中了。

但有个坑——如果两个断点设在同一地址，GDB会怎么处理？

我记得有一次，团队里有人抱怨GDB断点不生效。我过去一看，他在同一个函数入口设了三个断点，还都是条件断点。结果条件永远不满足，程序就一直在跑。嗯，条件断点虽然好用，但别滥用。

断点命中后，你输入c（continue）继续执行。这时候GDB要做一件很重要的事：把0xCC替换回原来的指令字节。

具体流程是这样的：

你可能会问：为什么要把0xCC写回去？因为断点还在啊！如果不写回去，下次执行到这个地方就不会再停了。

小技巧：如果你用disable临时禁用断点，GDB不会恢复原始指令，而是跳过检查。只有delete或enable才会真正修改内存。我个人习惯用disable来临时关闭断点，这样恢复时更快。

单步执行（step、next）其实也是基于断点实现的。GDB会在下一条指令处临时设一个断点，然后恢复执行。等断点命中后，再把这个临时断点删掉。

但这里有个性能问题：如果单步执行很多次，每次都要插入/删除断点，开销不小。我记得在调试一个循环100万次的代码时，用next单步走了几步就卡住了。后来我改用until命令，直接跳到循环结束，快多了。

避坑指南：我曾经在调试多线程程序时，用单步执行导致其他线程跑飞了。原因是GDB在单步执行时，只暂停了当前线程，其他线程还在跑。如果你需要同步调试所有线程，记得用set scheduler-locking on。

软件断点虽然好用，但不是万能的。我总结了几种场景，软件断点会失效：

遇到这些情况，就得用硬件断点了。不过那是下一节的内容，咱们先不展开。

下面这张图展示了软件断点的完整生命周期。从设置断点，到命中，再到恢复执行，每一步都离不开int 3指令。

从这张图可以看得很清楚：软件断点的本质就是指令替换。GDB在目标地址插入0xCC，程序执行到那里触发中断，GDB接管控制。恢复执行时再把原始指令换回来，然后重新插入断点。

整个过程看似简单，但每个环节都有细节。比如恢复执行时为什么要回退PC？因为0xCC执行完后，PC已经指向下一条指令了。如果不回退，原始指令就永远没机会执行了。

好了，软件断点的核心机制就这些。下次你用b命令设断点时，可以想想背后这些0xCC在默默工作。嗯，这就是底层的美妙之处。