1. 项目概述：为什么新手也需要掌握GDB？

如果你刚开始接触Linux下的C/C++编程，或者正在啃一些开源项目的源码，那么“程序崩溃了，但不知道死在哪里”或者“这个变量的值怎么和我想的不一样”这类问题，大概率会成为你的日常。面对一个黑漆漆的终端和一堆令人费解的错误信息，新手最容易陷入的困境就是“盲人摸象”——靠加打印语句（printf）来猜。加一次，编译一次，运行一次，效率低不说，还经常破坏现场，尤其是在处理并发或多线程问题时，打印语句本身就可能改变程序的执行时序。

这时，你就需要一个“时光机”和“显微镜”，能让你暂停时间，深入程序内部，查看任意时刻的内存状态、变量值、函数调用路径。这个工具就是GDB（GNU Debugger）。很多新手对GDB望而生畏，觉得那是“大神”才用的东西，命令行操作复杂难记。其实不然，GDB的核心逻辑非常直观，一旦掌握了几个基本命令，调试效率会呈指数级提升。这篇教程的目标，就是帮你拆掉这堵心理墙，用最直白的方式，带你从零开始，亲手用GDB抓住程序里的“虫子”（Bug）。我们不会罗列所有命令，而是聚焦于解决实际问题的核心流程和命令，让你在实战中快速上手。

2. GDB调试的核心思路与准备工作

2.1 调试的本质：控制与观察

在深入命令之前，我们先要理解调试器工作的两个核心：控制程序执行和观察程序状态。

• 控制执行：让程序在你指定的地方停下来（断点），然后你可以命令它“单步走”（step into/over）、“继续跑”（continue）或者“跳到下一循环”（until）。这就像导演在拍戏时喊“卡”，然后仔细检查当前场景的每一个细节。
• 观察状态：当程序暂停时，你可以查看任何变量的当前值、检查内存块的内容、查看函数是被谁调用的（调用栈）。这就像导演检查演员的妆容、道具的位置和剧本的上下文。

GDB的所有命令都是围绕这两个目标服务的。理解这一点，记忆命令就不再是死记硬背，而是有逻辑可循。

2.2 关键第一步：编译时加入调试信息

这是新手最容易忽略、也最致命的一步。默认的编译命令（如gcc -o test test.c）生成的是优化后的、给机器执行的二进制文件，其中不包含变量名、函数名、行号等对人类友好的符号信息。用这样的程序去调试，GDB看到的只是一堆内存地址和机器指令，你根本无法设置“在第10行断点”，也看不到“变量i的值”。

因此，在编译时必须加上-g选项。这个选项会让编译器在生成的可执行文件中嵌入完整的调试符号表。

gcc -g -o my_program my_program.c

对于稍微复杂的项目，可能还需要关闭编译器优化，因为优化可能会重组代码，导致行号对不上、变量被优化掉等问题。这时可以加上-O0（字母O后跟数字0）选项。

gcc -g -O0 -o my_program my_program.c

注意：-g和-O0通常只在开发调试阶段使用。发布版本时，为了追求性能，会去掉-g并启用更高级别的优化（如-O2）。

2.3 启动GDB的几种方式

准备好带有调试信息的可执行文件后，就可以启动GDB了。

1. 最常用方式：直接调试目标程序

   gdb ./my_program

   这会启动GDB并加载my_program，但程序并未运行，等待你输入命令。

2. 调试一个正在运行的进程如果你的程序已经作为一个服务或后台进程在运行，并且出现了问题，你可以“附着”（attach）到它上面进行调试。首先用ps或pidof找到进程ID（PID）。

   ps aux | grep my_program # 假设找到PID是 1234 gdb (gdb) attach 1234

   附着后，程序会立即暂停，你就可以像平常一样查看现场、设置断点了。调试完成后，使用detach命令让程序继续正常运行。

3. 分析程序崩溃产生的核心转储文件（Core Dump）当程序发生段错误（Segmentation Fault）等严重错误而崩溃时，如果系统设置允许，会生成一个核心转储文件（通常叫core或core.PID）。这个文件是程序崩溃瞬间的完整内存镜像。通过它，你可以在事后“复盘”崩溃现场。

   # 首先确保系统允许生成core文件 ulimit -c unlimited # 运行程序，假设它崩溃并生成了 core 文件 ./my_program # 使用GDB加载可执行文件和core文件 gdb ./my_program core

   加载后，GDB会停在程序崩溃的那条指令上，此时你可以查看当时的变量、调用栈，是分析复杂崩溃问题的利器。

3. 核心调试命令详解与实战演练

现在，我们以一个简单的有Bug的程序为例，来演练GDB的核心命令。假设我们有如下buggy.c文件：

#include <stdio.h> #include <stdlib.h> int faulty_sum(int *array, int len) { int sum = 0; for (int i = 0; i <= len; i++) { // Bug: 应该是 i < len sum += array[i]; } return sum; } int main() { int data[] = {1, 2, 3, 4, 5}; int result = faulty_sum(data, 5); printf("Sum is: %d\n", result); return 0; }

这个程序的Bug是数组越界访问（i <= len），在求和时会访问到data[5]，这是一个未定义的值，可能导致结果错误或程序崩溃。

编译并启动GDB：

gcc -g -O0 -o buggy buggy.c gdb ./buggy

3.1 运行与断点管理

启动GDB后，你首先会看到(gdb)提示符。

• 运行程序：run或r

  (gdb) run

  程序会从头开始执行，直到结束、遇到断点或崩溃。

• 设置断点：break或b断点是调试的基石。你可以通过多种方式设置：

  • 按函数名：b faulty_sum在函数faulty_sum入口处中断。
  • 按行号：b 6在当前源文件的第6行中断。
  • 按文件行号：b buggy.c:6在指定文件的第6行中断。
  • 按条件：b 7 if i == 4在第7行，仅当变量i等于4时才中断。这在循环调试中非常有用。

• 查看与删除断点：

  • info breakpoints或i b：列出所有断点信息（编号、位置、启用状态等）。
  • delete breakpoint [编号]或d [编号]：删除指定编号的断点。delete或d删除所有断点。
  • disable/enable [编号]：临时禁用/启用断点，而不用删除。

• 设置观察点：watch当某个变量或内存地址的值被改变时，程序会自动中断。这对于追踪谁修改了某个关键变量尤其有效。

  (gdb) watch sum

  设置后，每当sum的值发生变化，GDB就会暂停。

3.2 程序执行控制

设置好断点后，用run启动程序，程序会在断点处停下。此时，你可以精细控制它的执行。

• 继续执行：continue或c让程序从当前暂停处继续运行，直到遇到下一个断点、观察点或程序结束。

• 单步执行：

  • step或s：单步进入。执行下一行代码，如果该行是一个函数调用，则会进入该函数内部。
  • next或n：单步越过。执行下一行代码，但把函数调用当作一个整体一步执行，不会进入函数内部。这是最常用的单步命令。
  • until或u：运行直到。常用于快速跳出循环。例如，在循环体内使用until，程序会一直执行直到循环结束（跳出循环体）。

• 实战操作：

  (gdb) b faulty_sum # 在函数入口设断点 (gdb) run # 运行程序，会在faulty_sum开始处停下 (gdb) n # 多次按n，单步执行，观察循环 (gdb) p i # 在循环过程中，打印变量i的值（见下文） (gdb) watch sum # 设置对sum的观察点 (gdb) c # 继续，每次sum被修改都会停下

3.3 查看程序状态信息

程序停下来后，最重要的就是查看现场。

• 打印变量/表达式：print或p

  (gdb) p i # 打印变量i的当前值 (gdb) p array[i] # 打印数组元素 (gdb) p &sum # 打印变量sum的地址 (gdb) p/x sum # 以十六进制格式打印sum (gdb) p len # 打印参数len的值

  通过反复执行n和p i，你会清晰地看到i从0变化到5。当i为5时，p array[i]会打印出一个随机值（越界访问），这就是Bug所在。

• 查看内存：x(examine)print看的是变量，x命令直接查看内存地址的内容，功能更底层。

  (gdb) x/10w array # 从array地址开始，以字（word）为单位，显示10个元素 (gdb) x/1xg &sum # 从sum地址开始，以巨型字（giant word，8字节）为单位，显示1个，格式为十六进制

  格式说明：/后面的nfu，n是单元数量，f是格式（x十六进制，d十进制，c字符等），u是单元大小（b字节，h半字，w字，g巨型字）。

• 查看调用栈：backtrace或bt调用栈显示了程序执行到当前位置所经过的函数调用路径。当程序崩溃或停在深层函数时，bt是定位问题根源的第一选择。

  (gdb) bt #0 faulty_sum (array=0x7fffffffde10, len=5) at buggy.c:6 #1 0x00005555555551b9 in main () at buggy.c:15

  输出显示，当前在faulty_sum函数内（#0），它是由main函数（#1）调用的。你可以用frame [编号]命令切换到具体的栈帧，查看该层的局部变量。

• 查看局部变量与函数参数：info locals和info args

  (gdb) info locals sum = 15 i = 5 (gdb) info args array = 0x7fffffffde10 len = 5

  这两个命令能快速列出当前函数的所有局部变量和参数，比一个个p更高效。

3.4 动态修改与多线程调试

• 修改变量值：set variable调试时，你不仅可以观察，还可以干预。这常用于测试边界条件或绕过某些代码。

  (gdb) set variable i = 0 # 将循环变量i重置为0 (gdb) set variable len = 4 # 修改参数len，看看会发生什么

• 多线程调试基础如果程序涉及多线程，需要以下命令：

  • info threads：列出所有线程，当前线程前有*号。
  • thread [线程ID]：切换到指定线程进行调试。
  • break [位置] thread [线程ID]：在特定线程的特定位置设置断点。 在多线程环境中，观察数据竞争（Data Race）问题时，结合watch命令和线程切换非常有效。

4. 高效调试技巧与常见问题排查

4.1 让GDB更友好：配置与技巧

• 使用.gdbinit配置文件在你的家目录（~）下创建一个名为.gdbinit的文件，GDB启动时会自动执行其中的命令。可以在这里设置一些常用偏好，例如：

  set pagination off # 关闭分页，避免输出一屏后暂停 set print pretty on # 以更美观的格式打印结构体 define rr # 自定义一个别名命令‘rr’，用于重新运行 run end

• TUI模式GDB有一个文本用户界面模式，可以同时显示源代码、汇编和命令窗口。在GDB中按Ctrl+x再按a即可开启或关闭TUI模式。对于跟踪代码执行流非常直观。

• 命令补全与历史和Shell一样，GDB支持Tab键补全命令和文件名。上下箭头键可以翻看历史命令，大大提高输入效率。

4.2 典型问题排查实录

问题1：程序崩溃，显示“Segmentation fault (core dumped)”

• 排查步骤：
  1. 确保编译时加了-g。
  2. 运行ulimit -c unlimited允许生成core文件。
  3. 重新运行程序，产生core文件。
  4. 使用gdb ./my_program core加载分析。
  5. 输入bt查看崩溃时的调用栈。栈顶（#0）就是导致崩溃的函数和行号。
  6. 使用frame 0切换到崩溃栈帧，然后用info locals和info args查看当时的变量状态，基本就能定位到是哪个指针为NULL或越界了。

问题2：程序逻辑错误，但能运行，结果不对

• 排查步骤：
  1. 根据错误现象，推测可能出问题的函数或代码段。
  2. 在关键函数入口或可疑代码行设置断点（b）。
  3. 运行程序（r），在断点处停止。
  4. 使用n单步执行，同时频繁使用p [变量名]观察关键变量的变化是否与预期相符。
  5. 重点关注循环条件、边界值（如i=0或i=len-1）、函数返回值。
  6. 对于复杂条件，使用条件断点（b ... if ...）可以避免无效中断。

问题3：调试时想重复执行某段代码

• 技巧： 不要反复用run从头开始。可以在循环开始前设置断点，运行到那里后，通过set variable修改循环变量或条件，然后c继续，或者用jump命令（谨慎使用）直接跳转到指定行重新执行。

问题4：GDB提示“No symbol table found”或打印变量时显示“”

• 原因与解决： 这几乎百分之百是因为可执行文件没有调试信息。请务必确认编译命令中包含了-g选项，并且你正在调试的正是这个带-g编译出的程序。如果程序是动态链接库，也需要确保库文件是带调试信息编译的。

4.3 进阶工具链配合

GDB虽然强大，但纯命令行在查看复杂数据结构（如嵌套的STL容器）时不够直观。可以结合以下工具提升体验：

• GDB插件（如gdb-dashboard,pwndbg,peda）：这些插件为GDB提供了增强的UI，可以自动显示寄存器、内存、代码、栈等信息，对二进制安全分析尤其有用。
• IDE集成：Visual Studio Code、CLion、Eclipse等现代IDE都集成了GDB前端，提供了图形化的断点设置、变量监视、调用栈查看，大大降低了使用门槛。其底层调试引擎仍然是GDB。
• cgdb：这是一个基于终端的GDB前端，提供了类似Vim的分屏界面，上方显示源代码，下方是GDB命令窗口，兼顾了命令行效率和代码可视化。

掌握GDB，尤其是其核心的“控制-观察”逻辑和少数几个关键命令，是每一个在Linux环境下进行严肃开发的程序员必须跨越的门槛。它不仅能帮你快速定位和修复Bug，更能让你深刻地理解程序的运行时行为。开始时可能会觉得生疏，但强迫自己遇到问题先想“能不能用GDB看一下”，而不是急着加printf，经过几次实战，你就会发现它的效率远超你的想象。调试的过程，其实就是你与程序深入对话的过程。