★ FEATURED ARTICLE 简介一份面向C与C程序员的GDB调试入门及进阶指南以PPT形式系统讲解单步调试的核心方法。内容涵盖编译时加入调试信息、启动调试器、设置断点、逐步执行、查看变量和调用堆栈等基础流程并针对条件断点、观察点、异常捕获等高级技巧展开说明适合刚接触命令行调试的开发者快速上手也适合有一定经验者作为速查手册。资源是一个PDF文档压缩包内仅此单个文件大小约2.34MB便于保存、打印或离线阅读。文中给出大量命令示例和调试思路能够帮助读者理解程序执行状态、快速定位并修复代码中的逻辑错误同时掌握断点、观察点、捕捉点等常用调试手段的适用场景从而提升开发与排错效率。目前已有117人学习浏览尤其适合在Linux环境、嵌入式开发等需要GDB调试的场景中参考。1. GDB 单步调试详解这份 PPT 标题背后的落地路径单步调试看着简单实际翻车的人比想象多刚接触 GDB 的开发者常纠结 next 和 step 的区别老手也会被优化断点折磨到怀疑人生。《最新 GDB 单步调试详解 PPT.pdf》这个标题值得拆是因为它把调试从“打印日志碰运气”变成“一行一行看状态”程序走到哪、变量变成什么、分支条件是否成立全部摊开在眼前。这份标题能解决三类问题程序崩溃定位不到哪一行、业务逻辑错乱被 printf 误导、某个变量在时间点上被改掉。适合正在写 C/C 业务逻辑、嵌入式固件或做底层分析的人。我最早也靠 printf 猜直到某次调网络服务时输出顺序和实际执行完全对不上才下决心把 GDB 单步调试的边界彻底搞明白。下面会从原理讲到可复现步骤再摊开常见坑。2. 单步调试的底层逻辑断点类型与四条单步命令的执行边界2.1 软件断点与硬件断点断点命中不只是一条 int3GDB 的断点不是“暂停程序”这么简单。在 x86 平台上最常见的软件断点原理是GDB 把目标地址处的第一条指令临时替换成 int3 指令CPU 执行到 int3 就会触发一次异常操作系统把异常转给调试器。调试器保存当前线程的寄存器快照在命令行里等你发命令。当你输入 continue 或单步命令时GDB 再把这行的原始指令还原回去同时把指令指针回退一个字节让程序感知不到被修改过。硬件断点走的是另一条路径CPU 的调试寄存器可以设置一个地址程序访问该地址时直接触发调试异常不需要修改内存。这类断点对只读存储区、代码段不可写的嵌入式目标尤其有价值但数量非常少x86 上通常只有四个。数据观察点 watch 默认走硬件断点正是因为软件方案无法在每次内存访问时都做指令替换代价是数量受限。单步执行还有一层硬件机制。x86 的标志寄存器里有个陷阱标志位设定后 CPU 执行完一条指令就会触发一次调试异常。GDB 的 stepi/nexti 就是靠它完成的。至于源码级的 next/stepGDB 会在单步一条指令后检查当前执行位置对应的源码行号如果还在同一行就继续单步直到跨过一行源码为止。理解了这一层就能解释后面所有“一步跳三行”的诡异现象GDB 判断“是否跨过一行”靠的是行号表而行号表是编译器生成的优化编译会改变指令与源码行的对应关系。怎么验证当前用的断点类型在 GDB 里设完断点后执行 info breakpoints看 Type 列。软件断点一般显示 breakpoint硬件数据断点显示 hw watchpoint硬件执行断点显示 hw breakpoint。下面是我常用的确认方式(gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000401136 in main at demo.c:12 2 hw watchpoint keep y sumType 列是最直接的依据。如果在某个嵌入式目标上看到 pending breakpoint 或 cannot insert breakpoint通常说明 GDB 还没能把断点写到内存里原因可能是目标还没启动、内存被保护或地址超出了 RAM 范围。这种时候不要急着怀疑命令先确认断点类型和目标的存储属性是往正确方向排查的第一步。2.2 next、step、until、finish一次“步进”到底跨了多远这是 GDB 单步调试里最容易混的一组命令。next 的语义是“步过”它会把当前行的函数调用当作一个整体执行完停在调用返回后的下一行。step 的语义是“步入”如果当前行有函数调用它会跳进函数内部的第一行可执行源码如果没有函数调用它和 next 的区别不大。until 可以用来快速跳出循环比如在一个循环里执行 until 到循环结束后的行GDB 会一直执行直到目标行出现。finish 则是执行完当前函数然后停在函数返回处。看起来清晰实际用起来全是边界。next 判断“函数调用”需要符号表里有调用指令与源码行的映射step 进入函数后如果遇到没有调试符号的库函数GDB 往往直接继续而不是停下来。一个很常见的例子是调用 printf用 next 跳过 printf 没问题但用 step 进入 printf 时GDB 会提示“Single stepping until exit from function printf”然后直接跑完整个库函数停在后面因为 libc 没有调试符号。这不是 GDB 坏了而是它对“没有源码的函数”的默认策略。实操时连续步进的写法是命令后加数字。下面这组命令我已经用了很多年(gdb) next 3 # 连续步过 3 次遇到函数调用不进入 (gdb) step 2 # 连续步入 2 次每次进入函数体 (gdb) until 24 # 一直执行到第 24 行可用于跳出循环 (gdb) finish # 执行完当前函数停在返回地址处next 后面的数字表示“执行 3 条源码行”不是步进 3 条指令。step 后面的数字同理。这里有个隐藏陷阱如果某一次 step 进入了一个函数那么连续的 step 会先在该函数内继续函数返回后才会沿着调用点继续。所以 step 5 的实际轨迹可能是“进入函数 A走 3 行返回调用点再走 1 行”而不是傻瓜式地前进 5 行。想要严格按指令走应该用 stepi/nexti。源码级单步和指令级单步是两套计量单位不少血泪教训都来自把两者混用。until 的边界也值得展开。until 不带参数时会一直执行直到退出当前循环体适合在长循环里快速脱离until 带行号时等价于临时在那里设一个断点然后继续。但注意until 只能在当前栈帧有效如果你处在被调用函数里它不会跨函数返回后继续。finish 则是更明确的退出方式它执行到当前函数 return并打印返回值。如果函数永不返回比如死循环finish 就会一直挂住这时只能 CtrlC 打断再用 bt 看栈。从底层看next/step 的每一步都可能包含多条指令。GDB 内部执行的是“单步一条指令读行号对比是否离开当前源码行未离开则继续单步”。因此单步命令的耗时和当前行编译出的指令数量成正比。在 -O0 下一行往往对应几条到几十条指令在 -O2 下一行可能对应上百条指令而且指令可能被重排到相邻源码行之前或之后。这就是为什么高优化等级下“step 一下程序直接跑飞”的案例层出不穷。知道了这一层你就会习惯在需要看源码逻辑时用 -O0 重新编译在需要复现线上问题时再用 -O2 配合 disassemble。3. 从零跑通一个 GDB 单步调试会话最小可复现的命令序列3.1 准备样例程序带调试符号的 C 代码与编译参数我先放一个足够简单但能演示 next/step 差异的 C 程序。这个程序定义一个 add 函数main 里调用它两次最后打印一个整数。它本身没有明显的 bug但很适合用来观察单步行为#include stdio.h int add(int a, int b) { int result a b; return result; } int main(void) { int x 3; int y 4; int z add(x, y); int w add(z, 2); printf(result%d\n, w); return 0; }保存为 demo.c。编译时我会固定用这组参数gcc -g -O0 -fno-inline -o demo demo.c-g 生成调试符号表没有它 GDB 只能看到地址和汇编看不到源码行-O0 关闭所有优化强制保留一行源码到指令的对应关系-fno-inline 禁止函数内联避免 add 被内联进 main 变成零个函数调用那样 step 就没法演示“进入函数”。如果你的代码里有静态函数编译器仍然可能内联所以这个开关在调试期间非常关键。有人说 -O0 与线上行为不一致这确实存在但做源码级单步调试时的目标是看清逻辑不是复现性能等定位完再用 -O2 验证即可。编译后用 file demo 确认符号表在。一个容易忽视的细节不要用 -s 或 strip 命令处理产物否则后面的所有单步都无从谈起。如果项目用的是 CMake调试构建类型要设置成 Debug不要用 Release因为 Release 默认会加 -O2 并可能去掉调试信息。这是“调试 release 包”最常见的翻车点。3.2 启动调试器并设置断点break、run、list 的组合操作启动调试器最直接的方式是在命令行指定可执行文件gdb ./demo进入 GDB 交互界面后第一步不是 run而是 list 看源码行号。list 会按当前位置往后显示 10 行左右方便你给断点选行号。我一般先在 main 函数设一个断点(gdb) list 1 #include stdio.h 2 3 int add(int a, int b) { 4 int result a b; 5 return result; 6 } 7 8 int main(void) { 9 int x 3; 10 int y 4; 11 int z add(x, y); 12 int w add(z, 2); 13 printf(result%d\n, w); 14 return 0; 15 } (gdb) break main (gdb) info breakpointsbreak main 是“按函数名设断点”的写法等价于 break demo.c:8。GDB 收到这个命令后会在 main 的入口地址处插入软件断点。info breakpoints 用来确认断点编号、类型、状态和地址。设断点时也可以写文件加行号比如 break demo.c:11 会在 add 调用前停下这样能直接看参数传递前 x 和 y 的值。我建议你习惯带文件名的写法这样在多文件项目里不会混淆同名函数。启动程序用 run。后面带参数就是把参数传给被调试程序比如 run -v。run 不带参数则使用 GDB 内设置的 args。程序运行到断点就会停下来命令行变成 (gdb) 提示符(gdb) run Starting program: ./demo Breakpoint 1, main () at demo.c:8 8 int x 3;此时 GDB 已经把程序停在 main 的第一行还没有执行 int x 3。这里要留意断点命中时当前行的指令只是“即将执行”不是“已经执行”。所以 print x 会报“No symbol”或者给你一个初始垃圾值不要以为程序出了毛病。想要确认状态用 bt 看调用栈用 info locals 看局部变量。这一步是后续所有单步操作的地基。3.3 进入单步循环用 next/step/print 观察变量变化程序停在 main 第一行后我用 next 走完前三行并用 print 看变量。注意下面输出里行号的推进方式(gdb) next 9 int y 4; (gdb) next 10 int z add(x, y); (gdb) next 11 int w add(z, 2); (gdb) print x $1 3 (gdb) print y $2 4 (gdb) print z $3 7在第一个 next 前程序停在 main 入口第一条 next 执行 int x 3显示第 9 行第二条 next 执行 int y 4显示第 10 行第三条 next 执行整个 add(x,y)所以 z 被赋值为 7显示第 11 行。next 不进入函数所以你看不到 add 内部的 result 变化但 z 已经被算出来了。print z 能打印 7恰恰证明 next 确实把函数执行完了。如果想进到 add 内部看每一步必须用 step。我可以在第 10 行用 step 进入 add(gdb) step add (a3, b4) at demo.c:3 3 int add(int a, int b) { 4 int result a b; (gdb) next 4 int result a b; (gdb) print result $4 7 (gdb) backtrace #0 add (a3, b4) at demo.c:4 #1 0x0000000000401146 in main () at demo.c:10这里关键点step 在遇到 add(x,y) 时进入了函数体栈顶从 main 变成了 addbacktrace 能看到 main 还在下方等着。接下来 next 执行 int result abprint result 拿到 7。如果你想结束这个函数的单步用 finish 直接跑完 add 返回 main 第 11 行而不要一直 next 走下去。这是源码级单步调试里最常用的组合step 进入、next 单行、finish 退出。到这里你已经完成了一个完整的 GDB 单步调试闭环启动、设断、单步、查看变量、进出函数。剩下的事情是把这组操作固化成本能再叠加下一章的观察技巧效率会有明显提升。4. 把 print、watch、display 组合成观察窗口单步调试的效率关键4.1 用 watch 监控变量变化从“人眼盯”到“自动报警”单步调试最大的体力活是一直 print 某个变量。变量少还好变量一多每一步都手工 print 容易漏掉关键变化。watch 命令本质上是一个数据断点你告诉 GDB 监视一个表达式之后程序继续运行时只要这个表达式的值发生变化GDB 就立刻停下来并打印旧值和新值。用法是在某个变量已经存在的作用域里执行(gdb) watch sum Hardware watchpoint 2: sum (gdb) continue Continuing. Hardware watchpoint 2: sum Old value 0 New value 3这组命令的效果程序从当前位置继续运行一旦 sum 从 0 变成 3GDB 自动中断并报出变化。相比人眼盯 next 输出watch 可以让你放心地一直 continue 到变量变化点适合在长循环或后台任务里追变量。它的代价是数量限制x86 平台的硬件调试寄存器通常只有四个如果已经用了多个断点新 watch 可能失败原因正是硬件资源被占满不是命令写错。watch 还有两个变体。rwatch 是“读监视”表达式被读取时触发awatch 是“读写监视”读和写都触发。对内存踩踏类问题awatch 比普通 watch 有用因为你能看到非法访问发生在哪一条指令。注意 watch 表达式里不能调用函数比如 watch strlen(s) 是不行的因为 GDB 需要在每次停止时求值而调函数可能改变程序状态。另一个容易疏忽的是局部变量出作用域后 watch 会自动失效。GDB 会输出 “Watchpoint 2 deleted because the program has left the block in which its expression is valid”。这不是错误是变量生命周期到了。想让 watch 跨函数生效可以监控地址而不是变量名watch(int)var但要注意 var 必须在栈上且地址固定而且这种写法不会跟随栈帧销毁后的内存复用误报概率不低。4.2 用 display 持续展示表达式避免每步都敲 print如果每次单步都想看某几个变量的值敲 print 的效率太低。display 是更好的选择它把表达式注册到“自动显示列表”里此后每一次 next/step/continue 触发停止时GDB 都会自动打印这些表达式省去重复输入。(gdb) display sum 3: sum 0 (gdb) display /x $pc 4: /x $pc 0x401132 (gdb) next 4: /x $pc 0x401136 3: sum 3第一行 display sum 注册变量 sum第二行 display /x $pc 注册程序计数器按十六进制显示方便你对照汇编地址next 之后自动输出第二行可以看到 PC 变了sum 也变了。display 的输出编号是连续的冒号前是显示项编号冒号后是表达式和值。display 支持格式前缀/x 是十六进制/d 是十进制/s 是字符串/c 是字符。需要给某个变量调格式时可以用 printf %d 或者直接重新 display 一个带格式的表达式。取消显示用 undisplay 加编号(gdb) info display 3: sum 0 4: /x $pc 0x401132 (gdb) undisplay 3 (gdb) info display 4: /x $pc 0x401132display 最适合的场景是核心变量不多、你又想看完整变化曲线的定位过程。我一般会在进入一个可疑函数前把入参、循环计数器、累计量全部 display 出来再用 next 走几轮屏幕上每个变量的步进轨迹一眼就能对比出来。相比每次输入 printdisplay 还能避免某些变量在你敲命令的间隙发生变化的时序漏洞。4.3 用 record 和 reverse-step 实现反向调试给自己留一份后悔药反向调试是 GDB 里被低估的功能。普通的单步是“往前走”但程序状态是流水账错过一个变化就要从头再来。record 工具把程序的执行轨迹记录在内存里之后你可以用 reverse-step、reverse-next 往回走变量值也会回滚。调试那种“值在第 5000 次循环被改坏但前 4999 次都是正常”的问题时这个能力能救场。开启方式是在程序启动后、执行可能出错的区域前输入 record(gdb) record (gdb) continue (gdb) reverse-step (gdb) reverse-next (gdb) print sum例如我在 main 开头开启 recordcontinue 到断点后再 reverse-step程序会反方向退回上一条源码行的执行前状态print sum 可以看到当时的旧值。它的原理是把每一条指令执行前的内存和寄存器增量保存到环形缓冲所以开销不小运行速度会明显下降内存占用随执行轨迹线性增长轨迹过多时 GDB 会报 “Recording stopped: ran out of space for record buffer”。reverse 命令和正向命令是对应的反向也用 step/next/until/finish只是前缀改成 reverse-。需要注意record 不支持所有平台在嵌入式目标板上通常没有在本地 x86 Linux 上基本可用。还有一个限制record 与某些系统调用、多线程调度配合不好遇到 SIGSEGV 或进程退出后无法完整回放。所以我的用法是在已知问题区域前开启范围小、轨迹短成功率最高不要试图从头录到尾那是资源黑洞。4.4 条件断点与单步的组合只在特定状态停下条件断点是单步调试的天然搭档。与其在循环里一步步 next 到第 500 次不如直接写一个带 if 的断点让 GDB 只在你关心的条件成立时停下来。它的好处是减少无效步进让单步只出现在接近目标状态时注意力不会被无关代码分散。(gdb) break demo.c:12 if z 10 (gdb) continue这个写法表示每次运行到第 12 行GDB 都会求值 z 10只有为真才停止。条件表达式必须可求值不能包含未知符号如果表达式调用了函数GDB 可能会拒绝执行因为调试器求值时会打断程序语义。条件断点在每次命中时都会重新求值因此表达式开销越大continue 越慢但即便如此也远比手工按几百次 next 高效。条件断点还能替代部分观察点场景。当硬件观察点数量不足时你可以用条件断点监控一个地址上的值变化比如 break demo.c:16 if(int)p 5。这种方式牺牲的是速度换来的是不再受硬件寄存器数量限制。组合使用时我一般先设条件断点确认问题出现的位置再在那个位置前后使用单步和 display这样可以精确控制观察窗口不需要从程序开头一直单步走。5. GDB 单步调试避坑我踩过的 6 个典型问题与排查方法5.1 断点命中但 step 不继续优化级别把源码行映射打乱现象断点正常命中但执行 next 后 GDB 有时显示“当前行没有可执行指令”或者一下跳过三行甚至在空行上停住更夸张的是step 后程序直接跑飞单步命令仿佛失效。原因这是编译器优化导致的源码行映射错位。GCC 在 -O2 及以上会把多条源码行的指令合并也会把一条源码行拆成多个片段。调试信息里的行号表记录的是“指令与源码行的近似关系”而不是真实执行顺序。我某次调线上转储问题时明明 step 到第 45 行print 却显示第 42 行变量已经被修改就是因为编译器把两个 if 分支的指令重排到了一起。解决排查时先用 disassemble /m 看当前函数的反汇编与源码行对应情况。如果确认映射混乱最有效的办法是换成 -O0 和 -g 重建调试包还原可控的源码级单步。如果你的目的只是确认崩溃地址那用 disassemble 加断点地址比折腾源码行更直接。不要指望 GDB 能突破编译器的重排它只是读取行号表行号表错了再聪明的命令也没辙。5.2 next 直接跑飞函数调用被内联单步边界失效现象用 next 本想“跳过某个函数调用”但函数内部的语句在执行日志里出现或者 next 表现正常但 step 进入的是一个内联展开的巨大函数体一步一个坑。原因现代编译器在 -O1 及以上会自动内联静态函数和小函数。内联后函数调用在机器码层面不存在了取而代之的是被展开的指令块。GDB 判断“是否是一个函数调用”依赖调用指令没有调用指令next 自然不会把这段代码当作一步。我经常看到一种场景一个静态函数在调试版里被内联step 进去后没有栈帧bt 全是调用者的帧单步行为完全不符合直觉。解决调试期间编译加 -fno-inline从根上禁止函数内联。如果不想重新编译也可以在 GDB 里用 disassemble 查看目标地址附近是否有 call 指令确认到底有没有发生调用。当一个函数确实被内联而你又想单步看它内部可以临时改源码强制它成为独立函数或加 noinline 属性。最笨但可靠的办法是在任何可疑函数调用处用 step但配合 finish 快速退出别在里面迷路。5.3 观察点不触发硬件观察点数量限制与内存对齐问题现象watch 设好后 continue程序跑到了变量明显改变的位置但观察点一次都没触发有时 GDB 直接报错“Could not insert hardware watchpoint”。原因硬件观察点依赖 CPU 调试寄存器数量少且对访问粒度有要求。x86 平台一般只支持四个硬件断点或观察点如果你已经设了多个断点硬件资源可能耗尽。另一个更隐蔽的原因是变量存放在寄存器里而不是内存在优化构建下局部变量的生命周期可能在寄存器中完成硬件观察点只能监控内存地址所以观察点失效。这类问题在 -O0 下少见但一旦在 release 包上调试就会出现。解决首先用 info watchpoints 查看观察点状态如果显示“Target does not support hardware watchpoints”说明目标端能力不足或资源耗尽。减少当前断点数量或者用 watch -l 指定内存地址彻底排查。对一个频繁改写的变量可以尝试先把相关函数单独用 -O0 编译成 .o链接进 release 包局部变量回到内存后观察点就能持续生效。还要记得观察点表达式不要复杂尽量是单个变量避免 GDB 在每个指令周期都做完整求值。5.4 多线程程序单步行为诡异next 会切到另一个线程现象调试一个多线程服务next 执行后 GDB 显示停在了另一个线程的某一行或者 continue 后命中的断点线程不对单步的连续性被打断。原因GDB 的 all-stop 模式默认在任一线程停下来时把整个进程的所有线程都停止。单步命令本质上是让某一线程执行一步但调度器可能切换线程上下文加上断点命中事件可能来自其他线程于是屏幕上的“当前线程”频繁跳动。这个问题在 set scheduler-locking off 时尤其明显GDB 允许调度器在单步时切换其他线程。解决多线程调试时先执行 set scheduler-locking on把调度锁锁定在单步期间确保 next 只推进当前线程其他线程不执行。如果希望 continue 时也锁定可以用 set scheduler-locking step。想定位某个线程的栈用 thread apply all bt 看全量栈再用 thread 切到目标线程后再单步。不要在多线程现场直接暴力 continue否则大概率会被其他线程的断点反复打断。5.5 调试 release 包符号表缺失寄存器值不可读现象加载一个发布包后list 显示“No source file”break 只能按地址设print 变量名报“No symbol”单步调试基本没法做。原因发布版编译通常不加 -g或加完后又执行 strip符号表和源码行信息被移除。GDB 只剩 ELF 里的部分符号静态符号也可能被 strip 掉所以源码级功能完全不可用只能做汇编级调试。这是最常见也是令人最沮丧的场景。解决尽量在发布流程中保留带 -g 的符号文件单独存储调试时用 file 命令加载符号不把符号文件部署到线上。如果已经没留下任何符号可以用 objdump --syms 确认剩余符号再用 disassemble 和 info registers 做汇编级单步把关注点的数据放在寄存器和栈上用 /x $rsp 读返回值。不要浪费时间尝试让 GDB 恢复源码视角那是不可能的。一个折中做法是发布包不 strip保留外部符号至少函数名和行号还在单步到函数边界时仍能得到一些提示。5.6 程序不响应 continue陷入系统调用或死锁现象单步走到某处后 continue程序一直不回来等很久也没有输出CtrlC 打断后GDB 提示停在 __GI___lll_lock_wait 或 read 之类的系统调用里。原因程序在单步期间进入了阻塞的系统调用比如等待锁、等待 socket 数据或睡眠all-stop 模式下整个进程被停在“内核空间”断点没有机会触发所以看起来像挂死。如果多个线程都卡在锁上还可能是死锁bt 会显示每个线程都在等不同的锁。解决按 CtrlC 安全中断执行 thread apply all bt 查看所有线程栈确认是哪个调用点阻塞。对系统调用类问题可以在调用点之前用 catch syscall 预先拦截死锁则要看锁顺序找到两个线程各自持有对方需要的锁。单步调试时尽量避免在涉及阻塞 wait 的路径上长时间 continue优先用条件断点把目标点移到非阻塞区域再用 watch 观察关键状态。我的经验是单步调试死锁不划算应该先抓堆栈现场再根据锁序做静态分析。6. 把单步调试做成日常习惯TUI 界面与条件断点的组合用法当单步命令已经熟练下一步是让调试界面和断点策略更顺手。我一般会直接启用 TUI 模式在 gdb 启动时加 -tui 参数或者运行后按 CtrlX A 切换。layout split 可以让上方显示源码、下方显示反汇编layout regs 则可同时查看寄存器变化。这样 stepi 执行 C 语言的一个操作时下方汇编窗口能同步看到 PC 走到的位置对理解栈布局非常有帮助。gdb -tui ./demo (gdb) layout split (gdb) layout regslayout split 和 layout regs 可以随时切换如果界面乱了用 refresh 刷新用 winheight 调整窗口大小。TUI 模式下单步命令的观察效率明显高于纯命令行因为源码、汇编、寄存器三块信息同时可见。调试汇编级问题时我几乎全程开着 layout regs手动对照下一条指令和寄存器值的联动。条件断点则是减少无效步进的关键。与其在循环里一步步 next 到目标值不如直接在断点上加条件让 GDB 只在关键状态出现时停下来。比如一次调试任务里我在循环入口设了条件断点变量值达到异常阈值时才停配合 display 看历史轨迹几分钟就定位到了越界写。单步调试不是万能的但它能省下大量靠猜和 printf 的时间把工具边界记在心里比背命令更值钱。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
