2、GDB核心概念：断点、观察点、捕获点、变量监视的核心思想
调试的本质是什么？说白了，就是让程序在关键时刻「停下来」，让你看看它内部到底在搞什么鬼。GDB提供了几种不同的「停」法，各有各的脾气。我刚开始用GDB时，傻傻分不清断点和观察点的区别，结果浪费了不少时间。今天咱们就把这几个核心概念彻底捋清楚。
2.1 断点（Breakpoint）——最常用的「暂停键」
断点是最基础、最常用的调试手段。你告诉GDB：「在某个位置停一下」。这个位置可以是函数名、行号、甚至是文件+行号。
核心思想：断点关注的是「位置」——程序执行到指定代码行时暂停。
设置断点的方式很简单：
(gdb) break main # 在main函数入口停
(gdb) break 42 # 在当前文件的第42行停
(gdb) break foo.c:128 # 在foo.c的第128行停
(gdb) break func if x > 5 # 条件断点，x大于5时才停我个人习惯在调试复杂逻辑时，先用条件断点。为什么呢？因为普通断点每次经过都会停，如果循环100万次，你得按100万次continue，手都按酸了。条件断点能精准命中你关心的场景。
小技巧：我常用 info breakpoints 查看所有断点状态。注意看那个「Enb」列，y表示启用，n表示禁用。禁用断点用 disable 1，启用用 enable 1。
2.2 观察点（Watchpoint）——盯着变量不放
断点盯的是位置，观察点盯的是数据。你告诉GDB：「帮我盯着这个变量，它一变就停」。这在追踪变量被谁修改时特别有用。
核心思想：观察点关注的是「数据变化」——指定变量的值发生改变时暂停。
设置观察点：
(gdb) watch x # 当x的值变化时停
(gdb) watch *(int*)0x7fff # 甚至可以监视某个内存地址
(gdb) rwatch y # 当y被读取时停（只读观察点）
(gdb) awatch z # 当z被读取或写入时停（读写观察点）我曾经在项目中遇到一个诡异的bug：一个全局变量莫名其妙被改了，但代码里明明没有直接赋值。我翻来覆去看了三遍代码，眼睛都快瞎了。后来用 watch 一盯，发现是某个指针越界写到了这个变量的地址上。嗯，观察点就是这种场景的救星。
注意：观察点依赖硬件调试寄存器，数量有限（通常4个左右）。如果你设太多观察点，GDB会退化为软件模拟，调试速度会明显变慢。我建议一次最多设2-3个观察点。
2.3 捕获点（Catchpoint）——捕捉特殊事件
捕获点比断点和观察点更「高级」一些。它不盯位置，也不盯变量，而是盯事件——比如C++异常抛出、系统调用、fork子进程等。
核心思想：捕获点关注的是「事件」——程序发生特定事件时暂停。
(gdb) catch throw # 捕获C++异常抛出
(gdb) catch syscall write # 捕获write系统调用
(gdb) catch fork # 捕获fork调用
(gdb) catch signal SIGSEGV # 捕获段错误信号我记得有一次调试一个多进程程序，子进程一启动就崩溃，但父进程完全正常。用 catch fork 配合 set follow-fork-mode child，直接跟踪子进程的执行流程，很快就定位到了问题——子进程没有正确初始化某个全局变量。
2.4 变量监视——调试的核心目的
断点、观察点、捕获点，它们都是手段。最终目的是什么？是让你在程序暂停时，查看和修改变量的值。这就是变量监视。
GDB提供了丰富的变量查看方式：
(gdb) print x # 打印x的值
(gdb) print/x x # 以十六进制打印
(gdb) print &x # 打印x的地址
(gdb) display x # 每次暂停都自动打印x（自动显示）
(gdb) info locals # 打印所有局部变量
(gdb) p *array@10 # 打印数组的前10个元素修改变量值也很直接：
(gdb) set var x = 42 # 把x改成42
(gdb) set {int}0x7fff = 100 # 直接修改内存地址的值实战经验：我调试时经常用 display 命令。比如在循环中，把循环变量和关键结果都设成自动显示，每次断点停下时，GDB自动打印这些值，省得我一遍遍敲 print。
2.5 核心思想对比
为了让你更直观地理解这三者的区别，我整理了一个表格：
| 类型 | 关注点 | 触发条件 | 典型场景 |
|---|---|---|---|
| 断点 | 位置 | 执行到指定代码行 | 检查某个函数的执行流程 |
| 观察点 | 数据 | 变量值发生变化 | 追踪变量被谁修改 |
| 捕获点 | 事件 | 发生特定系统事件 | 调试异常、系统调用 |
2.6 知识体系图
下面这张图展示了GDB调试暂停机制的整体结构：
这张图把整个体系串起来了。你想想看，从「让程序暂停」这个目标出发，GDB给了你三种不同的暂停策略。每种策略都有自己的适用场景，没有哪个是万能的。我个人的经验是：调试初期多用断点，定位到可疑变量后用观察点，遇到系统级问题用捕获点。
避坑指南：我曾经在调试一个嵌入式程序时，设了观察点后程序跑得奇慢无比。后来发现是因为目标硬件不支持硬件观察点，GDB用了软件模拟——每执行一条指令就检查一次变量值。这种场景下，观察点慎用，优先考虑条件断点。
好了，这一章的核心内容就是这些。记住三个关键词：位置、数据、事件。理解了这三者的区别，你就掌握了GDB调试的「暂停哲学」。下一章我们会深入实战，看看这些概念在真实项目中怎么用。