一、调试器的抓手：ptrace 是谁？

Linux 系统提供了一个“后门级别”的系统调用：ptrace。调试器能控制程序、修改内存、查看寄存器，全靠它。它的意思直译就是“process trace”，让一个进程监视并干预另一个进程。

比如你让 GDB 启动一个程序，它其实是 fork 出一个子进程，然后在这个子进程执行前，执行了 ptrace(PTRACE_TRACEME)——意思是：“我愿意被调试。”

而如果你是调试一个已经在跑的程序，则 GDB 会直接 attach 上去：ptrace(PTRACE_ATTACH, pid)。

一旦绑定成功，目标程序发生的异常（比如段错误 SIGSEGV），或是你设置的断点命中产生的 SIGTRAP 信号，GDB 都能第一时间收到。

所以一句话总结：ptrace 是调试器和内核之间的桥梁，没有它，GDB 什么都干不了。

二、断点到底是怎么实现的？

当你敲下 break main 的时候，GDB 实际上是在悄悄修改你的程序代码。

它会定位到 main 函数的地址，然后把那一条机器指令的第一个字节，改成 0xCC——也就是 x86 架构下的 INT 3 指令。

INT 3 是 CPU 专门为调试准备的“中断”指令，执行它就会立刻抛出一个 SIGTRAP 异常。

于是程序一跑到这里，系统立刻把控制权交给了 GDB，GDB 再暂停程序、展示调试状态。

注意一个细节：你在 GDB 里看到的代码，是“原样”的。GDB 会在显示时把 0xCC 偷偷还原成你原本的指令，免得你看出破绽。

当你在断点处敲下 continue，GDB 可不会立刻放程序跑——它得先把断点位置的 0xCC 还原成原始指令，然后再想办法只执行这一条指令。

为什么这么麻烦？因为如果不这么干，下次程序跑到这，又不会停下来了。

于是 GDB 会：

这一套流程叫做“断点恢复 + 单步执行”，你看不见，但它每次都在背后完成，默默兜底。

x86 架构的寄存器里，有一个叫 TF（Trap Flag）的标志位。只要把它设置成 1，CPU 就会进入“单步模式”：每执行一条指令，就抛出一个 SIGTRAP。

GDB 就是通过 ptrace(PTRACE_SINGLESTEP) 告诉系统：“帮我把 TF 设一下。” 然后程序执行一条就停一下，GDB 再处理、再继续。

你每次按下 next、step，就是在让 CPU 这样一条一条地走。

普通断点是“你告诉我哪行代码停下来”，但 watch x 这种“我不知道谁改的它，但你帮我盯着”就更高阶了。

最笨的办法是：GDB 每条指令执行完，都去看看变量值变了没。但性能灾难。

更高效的办法是：靠 CPU 提供的调试寄存器。x86 有一组 DR0 到 DR7 寄存器，可以设置最多 4 个“监控点”，指定某个地址、访问类型（读、写、执行）。

只要变量的地址被写入，CPU 会立刻发出调试中断，GDB 收到 SIGTRAP，马上告诉你：“这个值被改了。”

硬件断点的好处是：性能高、即时响应，不影响程序正常运行。

你用 bt 看调用栈的时候，GDB 是怎么知道你是从哪层函数一路走下来的？

答案是：靠栈帧。

一般来说，每个函数调用会在栈上开一个“帧”，保存调用者的帧指针（RBP）和返回地址。GDB 会从当前的 RBP 开始，一层一层往上找，就能还原整个调用路径。

不过如果编译时用了 -fomit-frame-pointer 优化，那这个帧指针就不见了。GDB 就只能靠 DWARF 调试信息去猜，准确率可能会受影响。

GDB 能做到这些事，靠的是它“站在高处”：

这些组合在一起，就让我们能在源代码层面，观察一个机器层面正在执行的程序。

下次调试的时候，不妨想想：你看到的 main 停在了哪一行，其实背后是 GDB 在悄悄换指令、接管信号、走寄存器 —— 然后才在终端里，淡定地给你一个 (gdb)。