企业官网建设流程全解析

简介：这份《最新GDB单步调试详解PPT.pdf》面向使用GNU工具链的C/C++开发者与调试初学者，聚焦GDB命令行调试中单步执行、断点设置和程序状态观察等常见难点，适合课堂演示、自学查阅或项目排错时快速复盘。压缩包仅含1个PDF文件，约2.34MB，篇幅紧凑，便于在电脑或移动端直接翻阅。内容从编译时加入-g选项、启动GDB与加载符号讲起，系统梳理break、run、step、next、continue等命令，并延伸到观察点、捕捉点、信号处理、线程中断、条件断点及调用栈查看等进阶用法。文档配有命令示例与操作逻辑说明，可帮助读者理解程序暂停、逐行执行和变量检查的完整流程，提升定位缺陷与验证修复的效率。目前已有118人学习。

1. 拿到这份 GDB 单步调试 PPT 之后：先搞清楚它能替你省哪几步弯路

调试一个只在第三轮循环里把链表指针写坏的 C++ 服务，print打了十几行还是看不出哪一步出的问题——这类场景靠加日志只会越加越乱，真正省时间的是把 GDB 的单步链路走顺。这份《GDB 单步调试详解》PPT 把编译期-g、断点设置、next/step/finish的边界、观察点与信号处理串成了一条线，覆盖从启动调试器到查看调用栈的完整动作序列。它适合已经能写 C/C++ 代码、但对命令行调试器心里没底的开发者，也适合把 GDB 当插件后端挂在编辑器里、却一直没弄明白它底层怎么工作的那批人。下面按「先能停住、再能单步、最后能复现」的顺序拆开讲，每一步都给出可抄的命令。

2. 编译期的 -g 与调试符号：单步能不能走起来的第一道门槛

很多人第一次用 GDB 翻车的点不在命令敲错，而在编译那一步就漏了东西。GDB 并不读你的.c源文件来做单步，它读的是可执行文件里的调试信息段；没有这段数据，next和step就退化成在内存地址之间跳，你看到的全是0x80484e4这种值。这一章先把「调试信息是什么、怎么验证它在不在、缺了会有什么症状」讲透，后面所有单步操作才有落脚点。

2.1 -g 往可执行文件里塞了什么

gcc/g++加上-g之后，编译器会把 DWARF 格式的调试数据写进目标文件的若干个 section：.debug_info存函数、类型、变量的描述，.debug_line存「哪条机器指令对应源码第几行」的映射表，.debug_str存字符串池，.debug_abbrev存这些信息的编码格式。GDB 加载程序时解析的就是这几段，把运行时的指令地址反查回demo.c:12这样的位置。你敲一次next，它做的动作是：找到当前指令在.debug_line里对应的行号，算出下一行的起始地址，在那里下一个临时断点，然后继续跑。

这也是为什么-O2会让单步变得「不讲道理」。优化器会做循环展开、函数内联、把局部变量提到寄存器里，源码第 12 行和第 13 行的指令可能被交叉重排，.debug_line的映射随之扭曲，next走一步可能跳回上一行，也可能一次跨过三行。日常调试建议固定用-O0，需要兼顾性能时用-Og，它是专为调试保留的优化级别。

验证调试信息在不在，不用打开 GDB，readelf一行就够：

# 带调试信息编译 gcc -g -O0 -o demo demo.c readelf -S ./demo | grep -E "debug_info|debug_line" # 不带调试信息编译，作为对照 gcc -O0 -o demo_nodebug demo.c readelf -S ./demo_nodebug | grep -E "debug_info|debug_line"

前一条命令会列出.debug_info、.debug_line、.debug_str等若干段，后一条命令没有任何输出。参数含义：-g生成调试信息，-O0关闭优化保证行号映射和源码一致，-o指定输出文件名。readelf -S打印的是 section header 表，grep只是过滤出关心的几行，实际排查时还可以用objdump --dwarf=decodedline ./demo直接看行号表的原始内容，确认某一行是否真的被映射到了。

再补一个常被忽略的点：-g和-s（strip）是互斥的。发布包里如果执行过strip ./demo，调试段会被整段删掉，之后再用gdb ./demo打开就只剩地址。所以排障时要确认手上的二进制是不是被 strip 过，file ./demo的输出里如果有not stripped才算正常。

2.2 从源码到 gdb 载入的最小闭环

光看命令列表记不住，得有一份能跑起来的最小样例。下面这段程序故意做成三层链表加一个累加函数，既方便练next/step的进入退出，也方便后面在循环里设条件断点：

// demo.c —— 三层链表求和，用来练断点和单步 #include <stdio.h> struct node { int value; struct node *next; }; static int sum_list(struct node *head) { int sum = 0; while (head != NULL) { sum += head->value; /* 第 11 行，单步主战场 */ head = head->next; /* 第 12 行 */ } return sum; } int main(void) { struct node a = {1, NULL}; struct node b = {2, &a}; struct node c = {3, &b}; printf("sum=%d\n", sum_list(&c)); return 0; }

编译并进入调试器，整套动作控制在四条命令以内：

gcc -g -O0 -o demo demo.c gdb -q ./demo

gdb -q的-q是 quiet，省掉启动时那几行版权信息，输出干净；./demo作为参数直接传给 gdb，等价于进去之后再敲一次file ./demo。进入之后先确认符号加载成功：

(gdb) list (gdb) info functions sum_list

list不带参数时从当前源文件的第一个位置开始列源码，默认一次 10 行，再敲一次回车继续往下；info functions sum_list会输出sum_list的签名和它所在的源文件。如果list提示No symbol table is loaded，说明二进制没有调试信息，回到 2.1 重新编译，不要在 GDB 里继续折腾。

file命令还有一种用法值得记住：调试一个已经跑起来的进程或者 core 文件时，可以在 GDB 里用file ./demo手动挂载符号表，再用core-file core.1234挂 core。这套组合在线上排障时用得比想象中多，因为现场拿到的往往是单独一个 core，二进制路径可能已经变了。

2.3 符号表缺失的三种症状与判断顺序

同样是「单步不灵」，背后的原因可能完全不一样。按下面的顺序判断，能少走很多弯路：

这三种情况在初学阶段最容易混为一谈，尤其是第二种——源码明明就在眼前，next却像喝醉了一样来回跳，很多人会误以为是 GDB 版本问题，实际上是编译参数没对齐。养成习惯：进 GDB 之前先file一下二进制，确认with debug_info, not stripped，这一步只花两秒，能省掉半小时的自我怀疑。

3. next / step / finish 的边界：一行代码到底算到哪

单步调试的核心就三个命令，但「一行」的定义在不同上下文里差别很大：一行普通赋值、一行函数调用、一行带宏展开的表达式，next和step的行为完全不同。这一章把三个命令的语义拆开，再拿 2.2 的链表程序走一遍完整会话，最后讲怎么用条件断点把循环里的无效单步砍掉。

3.1 三个单步命令的进入与退出语义

next（简写n）执行当前行，如果这一行里有函数调用，它把整个调用当成一步走完，停在该行之后的下一行。step（简写s）执行当前行，遇到函数调用就进入被调函数的函数体，停在函数内的第一行可执行语句。finish则是从当前函数一路跑到返回，停在调用者的下一行，并把返回值打印出来。三者的差别可以这样记：next是「这行我信得过，跳过」，step是「这行我要钻进去看」，finish是「里面看够了，退出来」。

还有两个命令常被忽略但很实用。until（简写u）在当前循环体里一路执行到循环结束，遇到断点仍然会停，适合快速跳出一个已经确认没问题的循环。advance <行号>直接跑到指定行，中途不打印每一步，只在指定行或断点处停，比连续敲十几次next舒服得多。区别在于until是按循环边界走，advance是按明确的行号走，后者更适合跨越大段已知无问题的代码。

一个容易踩的细节：step进入函数的前提是这个函数有调试信息。如果step遇到一个没有符号的函数（比如系统库），它会直接把整个函数跑完再停，看起来就像next一样，这不是命令失效，是它没有可以停靠的源码行。后面 5.2 会专门讲这个场景怎么处理。

3.2 拿一份三层链表程序走一遍

用 2.2 的demo.c，从启动到退出走一遍完整会话，每条命令后面标上实际输出和下一步该看什么：

(gdb) list sum_list (gdb) break demo.c:11 (gdb) run

list sum_list把光标定位到函数附近，方便对照行号；break demo.c:11用的是「文件名:行号」的写法，比只写行号更保险，尤其是多文件工程里行号会重名；run（简写r）启动程序，第一次会在 11 行停下。接着单步：

(gdb) next (gdb) print sum (gdb) next (gdb) print head->value (gdb) continue

第一条next执行完sum += head->value，print sum应该输出3（第一个节点的值）；第二条next把head推到下一个节点，print head->value输出2。这三步的意义在于验证你对「当前行执行了没有」的判断：GDB 停在某一行时，这一行还没有执行，next之后才执行完。很多人第一次用会在停住时直接print一个本行才赋值的变量，看到旧值就以为程序有问题，其实是时序没对上。

再演示step和finish的配合。在main里对sum_list(&c)这一行敲step，会进入sum_list函数体；在函数里敲finish，GDB 会跑完整个函数并打印Value returned is $1 = 6，然后停在printf那一行。这个组合在排查「函数返回值不对」的问题时效率极高：不用逐行跟完整个函数，直接看返回值对不对，不对再重新进来逐行看。

(gdb) break main (gdb) run (gdb) step (gdb) finish (gdb) backtrace

最后那条backtrace（简写bt）打印当前调用栈，输出三行：sum_list、main、__libc_start_main。栈信息配合单步使用，能快速确认「我现在在哪一层、上一层是谁调的我」，尤其在递归和多层封装里，比盯着源码找调用点快得多。

3.3 条件断点配合单步：循环里少走冤枉路

单步最枯燥的场景是循环。一个跑 1000 次的循环，你想看第 500 次时某个变量的状态，逐次next显然不现实。条件断点解决的就是这个问题：

(gdb) break demo.c:11 if head->value == 2 (gdb) run (gdb) print head->value (gdb) print sum

break ... if <条件>里的条件表达式在每次到达该行时求值，为真才停。上面的写法让程序只在head->value等于 2 时停下，一次就命中了第二轮循环。参数上要注意两点：条件表达式里的变量必须在该断点位置可见，否则 GDB 会报No symbol "xxx" in current context；表达式求值本身有开销，如果循环体执行几百万次，条件断点会让程序明显变慢，这时候更合适的做法是先用一个普通断点定位大致范围，再缩小条件。

条件断点设错了不用退出重来，condition <断点号> <新条件>可以随时改，condition <断点号>不带条件则清除条件变成普通断点。断点号从info breakpoints里看，这个习惯建议从第一天就养成——后面断点一多，不记编号根本管不过来。

4. 断点、观察点与信号接管：让程序停在你想看的那一帧

单步解决的是「怎么走」，断点解决的是「在哪停」。GDB 提供的暂停手段不止break一种：变量被改写用观察点，异常抛出用捕捉点，信号到达用handle。这一章把这几种手段的参数和适用边界讲清楚，避免出现「明明设了断点却没停」的困惑。

4.1 break 的六种写法与条件断点参数

break（简写b）的完整形态比大多数人用的多，常见写法有六种：

(gdb) break demo.c:11 # 文件+行号，多文件工程首选 (gdb) break sum_list # 函数名，停在函数体第一条语句 (gdb) break demo.c:sum_list # 文件+函数名，避免同名函数冲突 (gdb) break *0x4005a6 # 内存地址，没有源码时用 (gdb) break demo.c:11 if sum > 2 # 条件断点 (gdb) tbreak demo.c:12 # 临时断点，命中一次后自动删除

break sum_list和break demo.c:sum_list的区别在大型工程里很明显：多个编译单元可能有同名的static函数，只写函数名时 GDB 只会给第一个匹配的位置下断点，剩下几个静默忽略，表现就是「代码明明走到这了却没停」。带上文件名能精确定位。tbreak适合「只想看一次」的场景，比如确认某个分支到底进没进，命中后断点自动消失，不用手动delete。

对于 C++ 的重载函数和模板函数，break需要给参数类型才能唯一定位，break foo(int)和break foo(double)是两个不同的断点。模板更麻烦一些，break foo<int>这种写法在部分 GDB 版本上支持不完整，稳妥的做法是先info functions foo看编译器实际生成的符号名，再用break 'foo<int>(int)'这种带引号的全名。这一条在没有 IDE 辅助的纯命令行环境里是血泪经验，报错信息往往只给你一句Function "foo" not defined，实际原因是名字没写全。

4.2 watch / rwatch / awatch 的适用边界

断点管的是「执行到某处」，观察点管的是「某个值变了」。三个命令的区别在于监控的读写类型：

实际用法是先让程序跑到变量有效的作用域内，再设观察点：

(gdb) break main (gdb) run (gdb) watch head->value (gdb) continue

顺序不能反。在main还没进入、head尚未初始化时设watch head->value，GDB 会报错说符号不可用。先停在变量已经存在的栈帧里，再下观察点，这是固定套路。

观察点有一个硬限制：它依赖 CPU 的硬件调试寄存器，x86 上一般只有 4 个。超过这个数量，GDB 会退化成软件观察点——每执行一条指令就检查一次表达式，速度会慢到无法接受。所以观察点适合盯一两个关键变量，不适合批量监控。真需要同时盯多个值，用条件断点更划算。

4.3 catch 与 handle：异常和信号怎么接管

catch用来在特定事件发生时暂停，最常用的是 C++ 异常：

(gdb) catch throw # 有异常被抛出时停 (gdb) catch catch # 异常被 catch 块捕获时停 (gdb) catch syscall write # 调用 write 系统调用时停

catch throw在排查「异常被上层吞掉、日志里看不到堆栈」的问题时特别好用：停在抛出点，bt一看就知道是谁抛的。catch syscall需要内核支持，不是所有平台都可用，用之前可以先catch syscall不带参数试试，能列出支持的系统调用名就说明可用。

信号处理用handle，参数分两部分：信号名和动作。动作有stop/nostop（是否暂停）、print/noprint（是否打印消息）、pass/nopass（是否把信号转交给程序自己处理）。典型场景是程序里注册了SIGPIPE的处理函数，但 GDB 默认会在信号到达时暂停，导致调试流程被无关信号打断：

(gdb) handle SIGPIPE nostop noprint pass (gdb) handle SIGINT stop print

第一条让SIGPIPE静默通过、交给程序自己处理；第二条让Ctrl+C仍然能中断调试。info signals可以列出所有信号的当前处理策略，排查「程序收到信号后行为异常」时先看一眼这张表，能排除掉一半的干扰。

4.4 断点生命周期管理：info、disable、delete、commands

断点一多就必须管。四个命令覆盖绝大多数需求：

(gdb) info breakpoints # 列出所有断点，含编号、命中次数、启用状态 (gdb) disable 2 # 停用 2 号断点，保留配置 (gdb) enable 2 # 重新启用 (gdb) delete 2 # 删除 2 号断点 (gdb) clear demo.c:11 # 删除该行上的所有断点

disable和delete的区别值得强调：disable保留断点编号和条件，随时可以enable回来；delete是彻底删掉，编号不再复用。调试过程中临时屏蔽某个断点用disable，确认不再需要才delete。

commands是这一节里最有价值的命令，它能让断点命中时自动执行一串动作，不用人工干预：

(gdb) break demo.c:11 (gdb) commands > silent > printf "head->value=%d sum=%d\n", head->value, sum > continue > end

这段配置的意思是：11 行断点命中后不打印默认的停靠信息（silent），打印一行自定义格式的变量值，然后自动继续（continue）。整个循环跑完，终端上就是一串整齐的变量变化记录，比手工敲几十次print高效得多。silent必须放在第一行，否则 GDB 会先打印它自己的停靠提示，输出会乱。这套写法在后面第 6 章做成脚本时会再次用到。

5. 避坑与排查：单步调试里最常见的五个翻车现场

前面几章讲的是「应该怎么做」，这一章讲「做了但没效果时怎么查」。下面五条都是实际调试中出现频率最高的，每条按现象、原因、解决三段写，遇到问题可以按顺序对照。

5.1 断点打在函数名上却没停住

现象：break sum_list显示Breakpoint 1 at 0x...，run之后程序直接跑完，断点一次都没命中，info breakpoints里命中次数是 0。

原因通常有三种。一是函数被内联了，-O2下static函数极容易被展开到调用点，函数入口地址在最终二进制里根本不存在，GDB 下断点时给的是一个已经不存在的位置。二是同名函数有多个，GDB 只给第一个匹配的下断点，实际执行的是另一个编译单元里的版本。三是函数还没被链接进来，比如动态库里的符号，需要先run起来让库加载后才能下断点。

解决：先file ./demo确认不是优化版本，重编时加-O0；多文件工程统一用break 文件名:函数名的写法；动态库符号用set breakpoint pending on允许在库加载前下断点，等dlopen之后自动生效。确认断点位置是否正确，可以info breakpoints看地址，再disassemble对照该地址附近的指令。

5.2 step 跳进库函数出不来

现象：在printf那一行敲step，画面切到了一堆没有源码的汇编，或者提示Single stepping until exit from function printf，然后卡在那里很久。

原因：step的语义是「进入被调函数」，但系统库通常没装调试符号，GDB 找不到源码行，只能在汇编层面一步步走，next也没法按源码行停。这不是 GDB 坏了，是它没有可用的行号信息。

解决：第一选择是敲finish直接退出当前函数，回到调用者；第二选择是一直next直到函数返回；第三选择是从源头避免，用skip命令把不关心的路径排除掉：

(gdb) skip function printf (gdb) skip file /usr/include/**

skip function让step遇到指定函数时当作next处理，不进入；skip file按文件路径排除。设置完用info skip查看当前规则，skip delete清空。如果确实需要看库函数内部，得装对应发行版的 debuginfo 包，装完list就能看到库的源码，但多数业务调试并不需要走到这一步。

5.3 print 出来是 optimized out

现象：程序停在断点上，print sum输出<optimized out>，info locals里一堆变量都是这个状态。

原因：编译开了优化，变量被放进寄存器或者被完全消除，DWARF 里记录的只是一个位置表达式，GDB 在运行时算不出有效地址。-O2下这种情况非常普遍，尤其是循环里的临时变量。

解决：重编译时降优化级别，-O0最稳，-Og在大多数场景下也能保住变量可见性。如果没法重编，可以disassemble看当前函数的汇编，结合info registers直接读寄存器值，比如print $rax看返回值、print $rdi看第一个参数（x86-64 调用约定）。这条路能救急，但可读性远不如有调试信息时直接打印变量。

5.4 多线程下断点到处乱停

现象：程序有四个工作线程，在一个线程相关的代码行上设了断点，结果任何线程走到这一行都会停，单步时线程来回切换，完全没法跟。

原因：GDB 默认是 all-stop 模式，任意一个线程触发断点，所有线程一起暂停；断点本身默认对所有线程生效，不区分是哪个线程触发的。

解决：用线程限定断点，break demo.c:20 thread 3只在 3 号线程命中；线程号从info threads里看，前面带*的是当前线程。单步跟代码时打开调度锁set scheduler-locking on，让只有当前线程跑，其他线程保持暂停；跟完再set scheduler-locking off恢复。这两个命令配合使用，多线程调试的混乱程度会下降一个数量级。

5.5 core 文件和二进制对不上

现象：gdb ./demo core.1234打开后bt全是??，函数名一个都看不到。

原因：core 是另一个版本的可执行文件产生的，或者二进制被重新编译过、被 strip 过。core 里存的是崩溃瞬间的内存镜像和寄存器，符号解析要靠配套的二进制，两者版本必须严格对应。

解决：找到生成该 core 的原始二进制，用file ./demo确认not stripped，再重新加载。确认 core 和二进制是否匹配，可以在 GDB 里敲info files，看Symbols from和Local core dump file两行是否指向预期路径。工程上更稳妥的做法是给每次构建打上版本号，core 文件名里带上版本和时间戳，避免事后翻箱倒柜找二进制。

6. 把单步序列固化成脚本：gdb -batch 与 .gdbinit 的两个用法

手工敲单步命令只适合一次性排查。真正反复出现的场景——比如每次改完代码都要确认某个函数的入参、某个分支的走向——应该把命令序列固化成脚本，一次编写反复执行。GDB 支持两种落地方案：命令行-batch模式和~/.gdbinit里的自定义命令。

先说-batch。它让 GDB 执行完-ex指定的命令后自动退出，不进入交互界面，适合放进 shell 脚本或自动化流程：

gdb -q -batch \ -ex "break sum_list" \ -ex "run" \ -ex "print head->value" \ -ex "print sum" \ -ex "continue" \ ./demo

这段脚本的作用是：在sum_list入口下断点，跑起来，打印第一个节点的值和初始sum，然后继续执行到结束。参数说明：-q去掉启动信息，-batch执行完退出，-ex每出现一次就执行一条命令，顺序即执行顺序。输出可以直接重定向到文件，和预期值做 diff，就变成了一个轻量的回归检查。我在排查「某个函数在特定输入下返回不对」的问题时，习惯先写这么一段脚本把关键变量打出来，确认是数据问题还是逻辑问题，再决定要不要进交互模式逐行跟。

再说.gdbinit。把常用配置写进家目录的这个文件，每次启动 GDB 自动生效，省掉重复输入：

# ~/.gdbinit set pagination off set confirm off set print pretty on define pv print $arg0 end define btfull backtrace full end

set pagination off关掉分页，输出不再停在--More--；set confirm off让quit、delete这类命令不再要求确认；set print pretty on让结构体多行展开，可读性明显提升。define定义的是自定义命令，$arg0是第一个参数，pv sum等价于print sum，btfull则是带局部变量的完整栈。这类小命令积累十几个之后，调试节奏会快很多。

最后一个我反复用的技巧：把第 4.4 节的commands和-batch组合起来，做成「无人工干预的轨迹记录」。在一个循环里设断点，commands里silent加printf加continue，再用-batch跑完，整个过程不需要人坐在那里敲回车，输出的就是一张变量随时间变化的表。从那以后我每次怀疑「某个值在中途被谁改了」，都强制先用这套方式打一遍轨迹，而不是一上来就watch——观察点受硬件寄存器数量限制，轨迹记录没有这个约束，覆盖面更广。希望帮到你。

本文还有配套的精品资源，点击获取