简介：《最新GDB单步调试详解PPT.pdf》面向C/C++、Fortran及汇编语言开发者与计算机专业学生，聚焦GNU调试器的命令行使用与单步调试流程，帮助读者从编译选项、断点设置到变量检查建立完整调试思路。内容覆盖gcc/g++的-g编译、GDB启动与符号加载，break、watch、catch、handle等暂停方式，以及step、next、continue的差异；同时讲解print/display查看变量、backtrace分析调用栈、list浏览源码，并延伸到条件断点、临时断点、线程中断与输出格式化等进阶技巧。资源包共1个文件，为1份PDF文档，大小约2.34MB，适合作为课堂演示、实验参考或查阅手册。已有118人学习，可用于系统梳理GDB操作命令与调试排错路径。

1. 程序跑着跑着就“不对劲”：GDB 到底是什么

写 C 或 C++ 的人大概都遇到过这种时刻：代码编译明明通过了，一运行结果就是不对，打印几行日志也看不出问题出在哪，只能靠猜。这时候老手往往会说一句“上 GDB 看看”。GDB 就是 GNU 调试器，一个跑在命令行里的程序“慢放机”——它能让程序停在你指定的位置，一行一行往下走，随时让你查看变量、内存和函数调用栈。这份《最新 GDB 单步调试详解》讲的就是怎么用它把程序拆开看清楚。只要你写过 C/C++、在 Linux 下编译过程序，哪怕从没打开过调试器，都能跟着从零上手。

2. 为什么值得学：先搞懂调试器能替你省掉什么

很多新手对 GDB 的第一印象是“黑乎乎的命令行，看着就头大”，于是继续用 printf 打日志。这在简单程序里没问题，但一旦程序有几层函数调用、有循环、有指针，日志就会变成一场灾难：你要反复改代码、重新编译、再运行，一个来回几分钟，一天下来全耗在这上面了。GDB 的价值就在于把这些来回全部省掉。

2.1 调试器和 printf 的差别到底在哪

先看一个最朴素的场景。假设你写了个循环，累加 1 到 100，结果输出不对。用 printf 的办法是：在循环里插一句打印，编译，运行，看输出，发现不对，再插一句，再编译……而用 GDB，你只需要在循环开始时停一次，然后一遍遍执行下一行，每走一步就打印一次变量，整个过程不用改一行源码，也不用重新编译。

更关键的是“现场”这个东西。程序崩溃的时候，printf 给你的只是崩溃之前你恰好打印出来的那点信息；而 GDB 能停住程序，让你看崩溃那一刻所有变量的值、函数是怎么一层层调过来的、内存里到底存了什么。这就是为什么很多老手说，调试器是唯一能让你看见程序内部状态的工具，其他手段都是隔着一层猜。

对新手来说还有一个隐形好处：用 GDB 单步走一遍代码，你会真正理解程序是怎么执行的。平时读代码是静态的，单步调试是动态的，走一遍之后很多“想不明白为什么这么写”的地方会突然通。所以学 GDB 不只是学一个工具，也是学一种理解程序的方式。

2.2 这份文档能给你什么

这份资料本身是一份系统的 GDB 单步调试讲解，从最基础的编译加-g、启动调试器，到断点、观察点、单步执行、查看变量和内存、调用栈回溯，再到信号处理和线程断点，是一条完整的线。它不是零散的技巧合集，而是按“先能跑起来，再能停下来，然后能看清，最后能控制”的顺序组织的，这个顺序恰好也是新手该走的路。

它覆盖的核心内容大致是这几块：怎么编译出带调试信息的程序、怎么启动和加载可执行文件、怎么用断点让程序在指定位置暂停、怎么用next和step一行行往下走、怎么用print查看变量、怎么用backtrace看调用栈、怎么用watch监控变量变化。对入门来说，前五块是必须掌握的，后面几块是锦上添花。

提示：GDB 主要用来调试 C、C++、Fortran 和汇编这类编译型语言写的程序，解释型语言用不上它。

2.3 什么时候你会真的需要它

不是所有问题都值得开调试器。打印一行就能定位的小问题，用 printf 反而更快。但下面这几种情况，GDB 几乎是唯一高效的选择：程序崩溃了但没有任何提示，只留一个段错误；某个变量在某个时刻莫名其妙变成了奇怪的值，你不知道是谁改的；一个函数被反复调用，你只想看第 100 次调用时参数是什么；程序卡住了不往下走，你想知道它停在哪个函数里。

这些情况的共同点是“状态不可见”。你看不到运行时的那一刻，程序里到底装了什么。GDB 做的就是把这层帷幕拉开。新手刚学时可能觉得不如图形界面顺手，但一旦熟悉几个基本命令，你会发现命令行的好处是精确、可重复、能写成脚本，而且几乎每台 Linux 机器上都有，不用装任何东西。

3. 第一步怎么迈：从编译到第一次停住

这一节是全篇最需要动手的部分。下面每一步都给出命令和解释，你照着敲一遍，就能完成人生的第一次 GDB 调试。建议在 Linux 环境下操作，准备一个简单的 C 源文件就行。

3.1 编译时必须加的那个 -g

GDB 要能看懂你的程序，前提是程序里带着调试信息。编译器默认生成的可执行文件里只有机器码，函数名、变量名、行号全被丢掉了，这种情况下调试器只能给你一堆内存地址，跟看天书差不多。加-g就是告诉编译器：把调试信息也塞进去。

# 假设源文件叫 demo.c，用 gcc 编译并生成带调试信息的可执行文件 demo gcc -g demo.c -o demo # 如果是 C++ 程序，换成 g++，参数含义完全一样 g++ -g demo.cpp -o demo

这里-g是核心，-o demo指定输出的可执行文件名。少了-g会怎样？程序照样能跑，GDB 照样能启动，但你设断点时没法用行号，打印变量时它会告诉你找不到符号。新手最常见的翻车现场就是这一步漏了-g，然后在 GDB 里折腾半天以为是命令用错了。所以养成习惯：凡是要调试的编译，先把-g带上。

顺便说一句，日常开发里常看到-g -O0一起用，-O0表示关闭优化。优化会让编译器重排、合并甚至删掉代码，调试时行号对不上、变量“消失”都是它干的。入门阶段建议明确写上-O0，少一类玄学问题。

3.2 启动 GDB 并让程序停在 main

编译好之后，进入调试环境只需要一条命令：

# 启动 gdb 并直接加载可执行文件 demo gdb demo

回车之后你会看到一个带(gdb)提示符的界面，这就说明已经进来了。如果你只敲了gdb没带文件名，也可以在提示符下用file demo把程序加载进来，效果一样。

接下来先看源码。输入list（简写l），GDB 会把源文件连同行号打印出来，一次显示十行左右，再敲一次回车就继续往下翻。这一步很实用，因为设断点要按行号来，你得先知道想停的那行是第几行。

# 查看源代码，可以带行号或函数名 list list 10,20 list main

然后设第一个断点。最直观的做法是让程序停在主函数入口：

# 在 main 函数入口处设置断点 break main # 运行程序，它会一路跑到断点处停住 run

执行run（简写r）之后，程序开始运行，走到main的第一行就停下来了。这时你会看到类似Breakpoint 1, main () at demo.c:5的提示，意思是断点 1 命中了，当前停在 demo.c 第 5 行。到这一步，恭喜，你已经完成了调试中最关键的一件事：让程序在你想要的位置停下来。

注意：如果run之后提示No symbol table is loaded，八成是编译时忘了-g，回去重新编译即可，不用怀疑命令。

3.3 next 和 step：一行一行往下走的两把钥匙

程序停住之后，就可以开始单步了。这里有两个命令，新手最容易搞混，但只要记住一句话就分得清：next是“执行这一行，但不进去”，step是“执行这一行，遇到函数就钻进去”。

# 执行下一行，如果这行是函数调用，整个函数当作一步执行完 next # 执行下一行，如果这行是函数调用，进入函数内部继续单步 step # 继续运行到下一个断点或程序结束 continue

举个例子。假设当前停在result = add(a, b);这一行，你敲next，程序会把add函数整个跑完，直接停在下一行；你敲step，程序会钻进add函数内部，停在函数体的第一行。什么时候用哪个？如果你怀疑问题出在add里面，就step进去；如果你确信add没问题，只想看后面的逻辑，就next跳过去。这个判断是调试的基本功，练几次就有感觉了。

还有个很实用的命令finish：当你在某个函数内部单步，想直接把这个函数跑完回到调用处，敲finish就行，它会顺便告诉你函数的返回值。另外next和step都可以简写成n和s，连敲回车会重复上一条命令，这是 GDB 里非常省事的一个设计。

3.4 用 print 看清变量的真面目

单步的意义在于每走一步都能查一次状态。查变量用print，简写p：

# 打印变量的值 print result print i # 打印时指定进制，/x 十六进制，/d 十进制，/c 字符 print /x result # 查看变量的类型 whatis result

这几条命令足够应付入门阶段的绝大多数场景。print的强项是它能算表达式，不只是变量名，print a + b、print arr[3]都行，甚至可以直接调用程序里的函数。新手可以先用最朴素的用法：走一步，print一下关键变量，看它是不是你期望的值。一旦发现某个值和预期不符，问题范围立刻缩小到“上一行到这一行之间”，这比盯着代码干想要高效得多。

如果想连续观察某个变量，每次停下来都自动显示它，可以用display命令，它会在每次程序暂停时刷新这个变量的值，适合放在循环里盯某个累加器。

4. 把“停住”用出花来：断点、观察点和调用栈

能停、能走、能看，入门的三板斧就齐了。这一节往前推一步，讲讲怎么让程序停在更精确的位置，以及停下来之后怎么看清“我是从哪来的”。这些是新手到能用之间最实用的一段路。

4.1 断点的几种设法和条件断点

break main只是最粗的用法。实际调试里，你更常需要在某一行、某个文件、某个函数上下断点：

# 在当前文件第 12 行设置断点 break 12 # 在指定文件的指定行设置断点 break demo.c:12 # 在某个函数入口设置断点 break add # 条件断点：只有 i 等于 100 时才停 break 12 if i == 100

条件断点是新手最该早点学会的一招。想象一个循环跑一万次，你在循环体里下了断点，程序会停一万次，你得敲一万次continue，这就是纯纯的血泪经验。加上if i == 100之后，只有满足条件的那一次才会停，其余全部自动跳过。这个功能在排查“某个特定数据出问题”的场景里几乎是神器。

断点设多了需要管理，常用的是这几条：info breakpoints查看所有断点及其编号，delete 2删掉编号为 2 的断点，disable 2暂时禁用，enable 2重新启用。禁用而不是删除，适合“这个断点待会儿还要用”的情况。

4.2 watch：盯着变量，谁改它就抓谁

有一种 bug 特别磨人：某个变量的值在某个时刻莫名其妙变了，但你不知道是哪一行改的。靠单步一行行找，代码长了会疯。这时用观察点：

# 变量值一发生变化就停住 watch count # 变量被读取时停住 rwatch count # 变量被读或被写都停住 awatch count

用法是先用断点让程序跑到某个位置，然后watch那个可疑变量，再continue。之后程序只要改动了这个变量，立刻停住，并且告诉你是哪一行改的。这相当于给变量装了个报警器，谁碰它一下就现形。新手排查“值被意外篡改”类问题，优先想到watch，往往比一行行单步快十倍。

4.3 backtrace：看清函数是从哪一层调过来的

程序停在某个函数里时，你常常需要知道“我是怎么走到这里的”。backtrace（简写bt）就是干这个的：

# 打印完整调用栈 backtrace # 只打印最上面的 3 层 backtrace 3 # 切换到第 1 层栈帧，然后就能查看那一层的变量 frame 1

它输出的是一串编号的调用链，从当前函数往上一直到main，每层都带函数名和参数。这份资料里也强调过，bt是分析程序行为的基本手段——崩溃时先bt一下，很多时候问题的位置就浮出来了。配合frame切换栈帧，你可以查看任意一层里的局部变量，相当于在时间轴上往回倒带。

4.4 一份入门阶段够用的命令清单

新手不用一上来记几十条命令，下面这张表里的够你用很久了。左边是完整命令，右边是简写和用途。

打印变量时还能加格式前缀，/x十六进制、/d十进制、/c字符、/f浮点，排查指针和内存相关问题时特别好用。资料里还提到用x命令查看内存，格式是x/nfu 地址，n是长度，f是格式，u是单位（b单字节、h双字节、w四字节、g八字节）。这块入门阶段了解即可，等真正需要看内存布局时再回来翻。

5. 新手最容易踩的 5 个坑

这一节单独拎出来，是因为下面这些问题几乎人人都会遇到一次，提前知道能省下大量怀疑人生的时间。每一条都按“现象、原因、解决”写清楚。

5.1 断点设了却不生效，提示找不到符号

现象：break main之后 GDB 说No symbol table is loaded，或者run起来后断点根本没停。

原因：编译时没加-g，可执行文件里没有调试信息，GDB 只能看到地址，看不到符号和行号。

解决：回去用gcc -g重新编译。如果确定加了-g还是不行，检查是不是编译和调试用的不是同一个文件，比如编译的是demo.c，GDB 加载的却是别处拷来的旧可执行文件。

5.2 单步时行号乱跳，变量显示“被优化掉了”

现象：next走一步，光标跳到毫不相干的行；print一个明明存在的变量，却提示optimized out。

原因：编译时开了优化（-O1及以上）。优化器会重排、合并、删除代码，源码和机器指令不再一一对应，行号和变量就都失真了。

解决：调试用的构建明确关掉优化，编译时加上-O0。发布构建再用-O2，两套分开，别混着来。

5.3 next 和 step 用反，一头扎进库函数出不来

现象：想跳过一行，结果敲了step，程序钻进了某个标准库函数或者深层调用，越走越深，完全找不到北。

原因：没分清next和step的区别——step遇到函数调用会进去，next不会。

解决：先判断这行有没有函数调用，只想往下走就next。万一已经钻进去了，用finish跑完当前函数回到调用处，或者直接continue到下一个断点，不用硬着头皮一行行退。

5.4 循环里下断点，程序停到天荒地老

现象：断点下在循环体里，run之后程序反复停住，敲了几十次continue还在循环里转。

原因：断点是无条件的，每次循环都会命中。

解决：改成条件断点，比如break 12 if i == 100，只有满足条件那次才停。如果已经设了普通断点，也可以先用disable禁掉，再补一个条件断点。

5.5 程序一运行就崩，来不及看现场

现象：run之后程序直接段错误退出，什么都没看清就回到提示符。

原因：崩溃发生在你设断点之前，程序没停过，自然没机会观察。

解决：先在main下断点，从入口开始单步，逐步逼近崩溃点；或者用backtrace在崩溃后查看调用栈（GDB 在程序异常终止时通常会保留现场）。养成习惯：不确定哪里出问题时，从main开始走，比盲目乱设断点稳得多。

6. 下一步学什么：一条能走通的路

走到这里，你已经能编译带调试信息的程序、启动 GDB、下断点、单步执行、查看变量和调用栈，入门该有的东西都有了。接下来最忌讳的是贪多——把资料里所有命令都背一遍，结果一个都没用熟。我建议按下面的顺序往下走，每一步都以“解决一个真实问题”为目标。

第一周，只练五个命令：break、run、next、print、continue。找一段自己以前写的、结果不太对的循环代码，从main开始单步走完，每走一步print一次关键变量。目标不是快，是熟悉“停下来看状态”这个节奏。

第二周，加上step、finish、backtrace。专门找有函数调用的代码练，故意在函数里单步进去，再用finish退出来，用bt看自己站在第几层。这一周结束，你应该能对任何一段几十行的程序说清楚它的执行路径。

第三周，练条件断点和watch。自己造一个“变量被意外修改”的小例子，用watch把它抓出来；再造一个循环一万次的例子，用条件断点只停在特定那一次。这两个技能在真实排查里出现频率极高，早点练熟非常值。

再往后可以按需扩展：多线程程序看info threads和线程断点；程序崩溃看 core 文件；需要自动化时把常用命令写进脚本。这些在资料里都有章节，但不必现在啃，等遇到具体场景再回头翻，吸收效率高得多。

最后说个我自己的教训。刚开始学的时候，我总想着一次把所有命令记全，结果真到程序出问题时，脑子里一片空白，还是回去加 printf。后来我给自己定了个死规矩：只要是编译型语言的程序出问题，先不加打印，强制自己走一遍gdb，哪怕最后还是靠猜。坚持了十来次之后，手就熟了，现在遇到段错误第一反应已经是bt而不是改代码。这个习惯帮我省下的时间，比任何技巧都多。希望帮到你。

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