简介：GDB作为GNU调试器，是C/C++开发者排查程序问题的利器。这份《最新GDB 单步调试详解PPT》从基础用法到高级技巧都有覆盖，既适合刚接触命令行调试的新手，也能帮助有一定经验的开发者补齐断点、观察点、捕捉点、信号处理等实用技能。资源为单个PDF文档，大小仅2.34MB，方便离线阅读。文档详细梳理了gcc -g编译、gdb启动、list查看源码、break设置断点、run运行、step/next/continue单步执行、print查看变量、backtrace分析调用栈等核心操作，并用示例命令说明条件断点、临时断点、观察点及格式化输出等进阶功能，内容贴近实际调试场景，能有效提升定位bug的效率。该资料已被117人学习，是值得收藏的GDB入门与进阶参考。
1. GDB 单步调试详解：为什么命令行调试器至今是排查 C/C++ 崩溃最快的路子
做过 C/C++ 服务端维护的人都有过这种经历：程序在客户环境跑上三天，突然段错误崩溃，日志停在最后一条消息，你手上只有一份 core 文件。这时候打开 IDE 点断点早就来不及了，真正能救场的是 GDB——这个 GNU 项目里最老牌的命令行调试器。很多开发者熟悉它的 run、break、next，但真正遇到"进入函数和跳过函数""观察点为什么没触发""bt 栈为什么是乱的"这类问题时，往往要现查资料。这份 GDB 单步调试详解文档覆盖了从编译参数、断点体系到信号处理、线程中断的完整链路，特别适合两类人：一类是刚把 C/C++ 语法学完、准备写真正的多文件项目的初学者，另一类是平时用 IDE 调试、需要切换到纯命令行环境排查线上问题的从业者。它不教你语法，教的是"怎么让程序按你的意志停下来"。
2. 编译与启动：没有 -g 的一切调试都是看地址
2.1 -g 参数的作用与验证方法
很多人第一次用 GDB 时都会问：为什么 list 命令看不到源码？为什么 print 一个变量显示的是内存地址而不是值？答案几乎都是同一个：编译时没加 -g。GDB 之所以能按行号断点、按变量名查值，靠的是可执行文件里的 DWARF 调试信息段。没有这段信息，GDB 拿到的是一个纯机器码文件，函数名、变量名全部丢失，只剩一堆地址。
# 不带调试信息编译 gcc test.c -o test # 带调试信息编译（推荐） gcc -g test.c -o test # 带调试信息并关闭优化（调试期强烈推荐） gcc -g -O0 test.c -o test这里说下参数含义。-g 生成调试信息，-O0 表示关闭编译器优化。为什么要关优化？因为开优化后编译器可能调整执行顺序、内联小函数、把变量直接塞进寄存器，你下一行的断点可能根本不执行。我见过最离谱的一次是 -O2 下断点打在 for 循环里，GDB 直接说断点位置是空的，就是因为循环被优化成了跳转指令。用 GDB 调试的正确姿势是先用 -O0 把逻辑摸清，再用 -O2 复现崩溃类问题。
2.2 三种启动方式与 file 命令的边界
启动 GDB 的最常见方式是直接跟可执行文件路径：
gdb ./test但实际工作中有几种情况需要其他方式。程序跑挂了生成了 core 文件，你想看崩溃现场，用gdb ./test core；程序是个常驻服务，已经有一个进程号，用gdb ./test <pid>直接 attach。后者在排查线上问题时尤其好用，但注意 attach 之后进程会暂停，多线程服务还得考虑业务影响。
进入 GDB 之后再加载文件也不是不行，file ./test就能手动加载符号。不过这里有个坑：如果执行文件的路径不对，GDB 会提示file not found，但它不会拒绝你进入交互环境，只是所有指令都会因为没有符号而失效。我一般习惯启动时直接带路径，这样可以提前发现文件缺失的问题。
3. 暂停程序的核心机制：断点、条件断点与捕捉点
3.1 基本断点：行号、函数名与内存地址
GDB 的暂停机制是整套调试流程的地基，原文档把它总结为四种手段：断点、观察点、捕捉点、信号。其中最常用的是断点，break 命令支持按行号、函数名和内存地址三种方式定位。
# 按行号设置断点，在第 16 行停下 break 16 # 按函数名设置断点，进入 func 函数时停下 break func # 按文件名+行号，多文件项目里最常用 break test.c:24 # 查看所有断点 info break按行号断点需要先用list查看源码确认位置，按函数名断点则没有这个烦恼，直接写函数名就行。多文件项目里推荐用文件名:行号的写法，因为多个文件里可能出现相同的行号，GDB 默认是相对当前源码文件定位的。设置完成后可以输入info break查看断点编号、地址和状态，这个输出里 Enb 一列表示该断点是否启用，y 是启用，n 是禁用。
3.2 条件断点：break if 的循环场景与常见误用
循环体里的断点是最让人头疼的——如果每轮循环都停，你得手动 continue 几百次才能到真正想检查的那次迭代。GDB 的条件断点就是干这个的，原文档给了一个很典型的例子：break 46 if testsize==100，含义是当 testsize 等于 100 时在第 46 行停下。
# 在循环体第 20 行设置条件断点，i 等于 50 时停住 break 20 if i==50 # 更复杂的条件：多个变量参与判断 break func if (n > 100 && flag == 1)写条件断点时最容易翻车的两点：一是条件里用了未初始化的变量，GDB 在某些情况下会直接把条件当作恒真处理；二是变量名写错，GDB 不会报错，但断点永远不触发。我的经验是设置完条件断点后，先print i看一眼当前值，确认变量名和类型都对得上，再开始 run，省得跑半天发现断点是摆设。
3.3 观察点与捕捉点：watch 的写时暂停和 rwatch 的读时暂停
断点解决的是"到达某个位置停下"的需求，观察点解决的是"某个变量的值发生变化就停下"的需求。原文档列了三种：watch 是变量值被写时停，rwatch 是变量被读时停，awatch 是读或写都停。
# 观察变量 count，被修改时暂停 watch count # 观察数组元素，指针指向的位置被修改时暂停 watch buffer[10] # 观察表达式，这个表达式的值变化时暂停 watch n * 2 + 1观察点与断点最大的区别在于它不需要指定行号，完全按数据流走。排查"这个值到底在哪里被改掉"的问题时，观察点是效率最高的工具。但注意观察点在变量是局部变量且所在函数返回后会自动失效，GDB 会提示Watchpoint 2 deleted because the program has left the block in which its expression is valid，这时候别慌，重新在函数入口设置一个断点，进入函数后再设置观察点即可。
捕捉点用的场景相对少，catch throw可以捕获 C++ 抛出的异常。很多 C++ 开发者不知道 GDB 能直接在异常抛出时停住，结果用断点从 main 开始一路 step 进库函数，费了半天劲。原文档特别注明，exec、fork、vfork、load 这些捕捉事件目前只在 HP-UX 上有效，Linux 下用catch fork直接不支持，这个别抱期望。
4. 信号与线程断点：多线程调试的两把钥匙
4.1 handle 命令：控制信号的分流方向
信号处理是 GDB 调试里最容易被忽略的功能。程序收到 SIGSEGV（段错误）时默认行为是停住并打印断点信息，但有些信号默认是不停的。比如 SIGPIPE，管道写端被关闭时进程收到它，GDB 默认把信号交给程序，程序如果没做处理就直接退出。想排查这种场景，得用 handle 命令手动指定行为。
# 收到 SIGPIPE 时停住程序，便于检查写管道时对端是否关闭 handle SIGPIPE stop print # 忽略 SIGUSR1，GDB 不停住也不打印消息，继续运行 handle SIGUSR1 nostop noprint pass # CTRL+C 发的 SIGINT 默认 stop，可以显式指定 handle SIGINT stop print原文档把 handle 的五个参数总结得很清楚：nostop 不停但打印消息，stop 停住，print 打印收到信号的消息，noprint 不打印，pass/noignore 表示把信号交给程序处理，nopass/ignore 表示截住信号不让程序收到。日常排查时最常用的是handle SIGSEGV stop print——虽然默认就是这行为，但在某些自定义信号掩码的程序里，GDB 未必能正确暂停，手动指定一次相当于上了一道保险。有个细节：信号名必须大写，写sigpipe是无效的。
4.2 线程断点：thread 参数指定线程编号
多线程程序的调试和单线程完全是两个世界。GDB 默认在断点触发时，所有线程都会停。原文档给出的线程中断语法是break linespec thread threadno if...，意思是给某个指定线程设置断点。
# 查看当前所有线程的 ID info threads # 只在线程 3 上给 func 函数设断点，其他线程照常跑 break func thread 3 # 只在线程 3 上设条件断点，i 等于 100 时停 break test.c:24 thread 3 if i==100线程编号不是系统分配的 TID，而是 GDB 自己维护的 ID 序号，通过info threads查看，输出里第一列带 * 号的是当前线程。注意程序刚启动时所有线程可能还没创建，此时在某个线程上设断点会失败。常见做法是在 main 函数停下来，此时各个线程已经创建完毕，再输入info threads拿到编号，然后设置线程断点。另外原文档还提到break test.c:12这种文件:行号写法，在多线程并行执行同类任务时，配合条件断点可以精确只停特定线程，避免每个线程都停导致调试体验极差。
5. 避坑手册：查看数据与栈回溯中的五个翻车现场
5.1 print 出垃圾值：未初始化变量与格式符错用
现象：print i输出一个像 134513808 的奇怪数字，和代码里看到的逻辑完全对不上。
原因：变量从未被初始化。原文档的示例里，进入 func 函数后print i就出现过这种值，本质是这块栈内存里残留了上一次调用的数据。另一层原因是 print 默认按变量的自然类型输出，遇到指针输出的是地址而非指向的内容。
解决：先用whatis i确认变量类型，再用print *ptr解引用指针。需要按指定格式查看时用/加格式符，print /x i看十六进制，print /c i看字符。最实用的组合是字符串指针print /s pFilePath，直接输出完整字符串而不是首个字符地址。
5.2 watch 观察点在函数退出后失效
现象：在某函数的局部变量上设置了 watch，函数返回时 GDB 提示观察点已删除，后续修改完全没监控到。
原因：局部变量的生命周期属于栈帧，函数出栈后该地址已被释放。
解决：把观察点设在对堆内存或全局变量上。如果必须观察局部变量，做法是先在函数入口下断点，进入函数后再重新设置观察点。另一个经验是观察表达式不要写成watch p这种裸指针，而是watch *p要么观察指针本身变化要么观察指向内容变化，二者一混容易晕。
5.3 没加 -g 直接调试：所有变量名都找不到
现象：break func提示找不到函数，print result提示变量不存在，但程序明明有这个符号。
原因：编译时没加 -g，可执行文件不包含调试符号。这种情况 GDB 退化为只能看汇编，能看到的是 memory address。
解决：重新编译。如果线上二进制没法重编，可以用info functions和info variables先看有哪些符号可用，至少能通过地址断点break *0x8048456方式设置断点。但这种方法定位问题的成本极高，通常只用于确认崩溃位置，真正的排查还得靠带 -g 的版本。
5.4 条件断点永远不触发：条件静默失败
现象：设置了break 20 if n == 100，全程跑完一次都没停。
原因：最常见的两个，变量名拼错，GDB 把未知变量当作常量 0 处理，条件恒为假；或者变量类型不对，比如 n 是 float，和整数 100 比较永远不等。
解决：先print n在普通断点下看一眼实际值，再用info breakpoints查看断点是否设置成功。GDB 的条件断点不会对表达式做类型强制转换，浮点比较务必写成n > 99.9 && n < 100.1这种区间判断。
5.5 bt 栈信息不完整：优化导致栈帧缺失
现象：backtrace输出只有一两层，明显少于预期的函数调用链。
原因：编译器开优化后可能把某些函数内联展开，栈帧直接没了。另一个原因是程序发生了栈溢出，栈指针已经被破坏，GDB 无法继续回溯。
解决：用bt full看每层栈的局部变量，用frame n切换到指定层级检查参数值。若确认是栈溢出，就要检查栈空间大小和递归深度，这类问题 GDB 能显示出的信息非常有限，需要结合 core 文件做离线分析。
6. 单步执行的进阶技巧：用 finish 和 until 替代无脑 next
单步执行最基础的一对命令是 next 和 step，next 不进入函数内部，step 进入函数内部。原文档的示例里反复用 next 单步走循环体，配合 print 观察变量值变化。但真正到了实战，有一个比 next 更精准的工具——finish，它的作用是直接运行完当前函数并返回，同时打印返回值。当你不小心 step 进了一个底层库函数，比如 printf 的内部实现，用 finish 一秒逃出来，比一直按 next 循环几十次高效得多。
# 在 func 函数内部输入 finish，直接执行到函数返回 finish # 输出示例：Value returned is = 31375 # 不用在函数里一步步走完剩余逻辑另一个实用技巧是 combination 使用 break 和 disable。在循环体内设置一次条件断点，命中后先用print确认值符合预期，再输入disable 2禁用这个断点，然后continue就能一跑到底而不被反复打断。配上display i让 GDB 每停一次自动打印 i 的值，比每次手动输入 print 省不少事。
# 设置 i 的自动显示，每次程序暂停时自动打印 display i # 输出示例：1: i = 50 # 不需要再手动 print我在处理一次死循环问题时，就是靠 watch 加 display 组合定位的。循环变量被某个回调函数里的指针越界写坏，普通断点根本看不出哪一步改的，watch 一挂上五分钟就逮到了元凶。从那以后我每次拿到崩溃类问题，都强制自己先想清楚"该用断点还是观察点"，而不是一上来就 next 到底。这份 GDB 单步调试详解文档最大的价值在于把命令行调试的完整地图摊开了，花一小时读完再上手，比抱着 GUI 调试器摸索一个月学到的东西更系统。希望帮到你。
本文还有配套的精品资源，点击获取
