1. 从“黑盒”到“透视”：为什么你需要GDB
如果你刚开始接触Linux下的C/C++编程，大概率经历过这样的场景：程序编译通过了，但一运行就“啪”地一下崩溃，终端只留下一行冰冷的Segmentation fault (core dumped)。或者，程序没有崩溃，但输出的结果和你预想的完全不一样，你盯着几十行、上百行的代码，不知道到底是哪一行逻辑出了问题。这个时候，你就像面对一个不透明的黑盒子，只能靠printf大法，在代码里到处插入打印语句，祈祷能撞对位置。这个过程不仅低效，而且对于复杂的逻辑流或并发问题，几乎无能为力。
GDB（GNU Debugger）就是为你打开这个黑盒子的“透视镜”。它不是另一个需要你记忆大量命令的负担，而是一个强大的交互式侦探工具，让你能暂停程序的任意时刻，查看当时所有变量的值，观察函数调用栈的来龙去脉，甚至像导演一样，让程序逐行执行，或者跳转到任意位置。对于新手而言，掌握GDB最直接的价值在于：它能将你从盲目猜测的泥潭中拉出来，用确定性的观察取代不确定性的试错。网络上搜索“gdb调试”、“gdb调试常用命令”的热度，恰恰说明了这是每个开发者从“能写代码”到“能搞定代码”的必经之路。
很多人觉得GDB门槛高，命令难记，宁愿用IDE集成的图形化调试器。这当然可以，但理解GDB的核心操作，能让你在任何纯命令行环境（比如远程服务器、嵌入式设备）下游刃有余。更重要的是，它帮你建立对程序运行时状态的底层认知，这种认知是图形化界面无法完全替代的。今天，我们就彻底抛开畏惧，从零开始，让GDB成为你手中顺手的工具。记住，我们的目标不是背命令，而是理解“调试”这件事，GDB只是实现这个目标的工具。
2. 前期准备：编译出“可被调试”的程序
在请侦探（GDB）来调查之前，你必须先准备好一个“允许调查”的现场。一个直接gcc编译出来的程序，默认是“优化且剥离”的，就像犯罪现场被清理过一样，GDB会找不到任何线索（变量名、行号信息）。因此，第一步总是正确的编译。
2.1 关键编译选项：-g
-g是GCC/G++编译器的调试信息生成选项。它的作用是在生成的可执行文件中，嵌入源代码的行号、变量名、函数名、数据类型等符号信息。这些信息本身不会影响程序的执行逻辑，但却是GDB能够将机器指令与你写的C代码对应起来的唯一依据。
一个最基础的编译命令如下：
gcc -g -o my_program my_program.c这里，-g生成了调试信息，-o my_program指定了输出文件名。
注意：
-g和优化选项（如-O1,-O2）通常可以一起使用，但高等级的优化（如-O2,-O3）可能会改变代码的执行顺序、内联函数、省略某些变量，导致你在GDB中看到的代码行、变量值可能与你的源码逻辑不完全对应，增加调试难度。对于新手，建议在调试阶段使用-g -O0（-O0表示关闭所有优化），确保调试体验最直观。
2.2 一个简单的调试示例程序
光说不练假把式，我们创建一个有典型问题的小程序来作为贯穿本教程的案例。创建一个名为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++) { // 错误：应该是 i < len sum += array[i]; } return sum; } int main() { int data[5] = {1, 2, 3, 4, 5}; int result = faulty_sum(data, 5); printf("The sum is: %d\n", result); // 另一个常见问题：未初始化指针 int *ptr; printf("Uninitialized pointer value: %d\n", *ptr); // 这里会导致Segmentation fault return 0; }这个程序有两个经典问题：
- 在
faulty_sum函数中，循环条件i <= len会导致数组越界访问（访问了data[5]），这是一个未定义行为，可能引发奇怪的结果或崩溃。 - 在
main函数中，指针ptr未初始化就被解引用，这几乎必然导致段错误。
现在，用调试模式编译它：
gcc -g -O0 -o buggy buggy.c如果编译成功，你就得到了一个携带完整调试信息的可执行文件buggy。接下来，就是GDB登场的时候了。
3. GDB基础操作：启动、运行与查看
3.1 启动GDB与加载程序
启动GDB并加载我们的程序有两种常用方式：
方式一：启动GDB时直接指定程序
gdb ./buggy这种方式会直接启动GDB并加载buggy程序的符号信息。
方式二：先启动GDB，再加载程序
gdb (gdb) file ./buggy在GDB交互提示符(gdb)下，使用file命令来指定要调试的程序。file命令也用于在调试过程中切换不同的可执行文件。
启动后，GDB会输出一些版本信息，并停在(gdb)提示符下，等待你的命令。此时程序尚未开始运行。
3.2 运行程序与传递参数
使用run或r命令开始执行被调试的程序。如果你的程序需要命令行参数，可以直接跟在run后面。
(gdb) run # 或者带参数 # (gdb) run arg1 arg2对于我们的buggy程序，直接run。你会看到类似下面的输出：
Starting program: /path/to/buggy The sum is: 15 Uninitialized pointer value: Program received signal SIGSEGV, Segmentation fault. 0x0000555555555253 in main () at buggy.c:18 18 printf("Uninitialized pointer value: %d\n", *ptr);程序打印了第一行结果（“The sum is: 15”），然后在试图打印未初始化的指针时崩溃了，GDB捕获到了段错误（SIGSEGV）并自动暂停了程序，告诉你崩溃发生在buggy.c的第18行。
实操心得：程序崩溃后，GDB会停在导致崩溃的那一行代码上。但根本原因可能不在这一行。比如这里，崩溃是解引用
ptr导致的，但问题根源在于ptr没有初始化。GDB帮你定位了“事故现场”，但“事故原因”需要你进一步侦查。
3.3 查看代码（list）
当程序暂停时（无论是崩溃、断点还是单步执行），你常常需要查看当前的源代码上下文。list或l命令用于显示源代码。
list: 显示当前行附近（通常是前后共10行）的代码。list 行号: 显示指定行号附近的代码。list 函数名: 显示指定函数开头的代码。- 按回车键会重复上一个命令，对于
list，按回车会继续往下显示代码。
在我们的例子中，崩溃后输入list：
(gdb) list 13 int main() { 14 int data[5] = {1, 2, 3, 4, 5}; 15 int result = faulty_sum(data, 5); 16 printf("The sum is: %d\n", result); 17 int *ptr; 18 printf("Uninitialized pointer value: %d\n", *ptr); 19 return 0; 20 }这清晰地展示了崩溃点周围的代码。
3.4 查看变量与内存（print / examine）
调试的核心是查看程序内部状态。print或p命令是使用最频繁的命令之一，它可以打印变量、表达式甚至内存地址的值。
打印基本变量：
(gdb) print result $1 = 15 (gdb) p data $2 = {1, 2, 3, 4, 5}GDB会为每次打印结果分配一个以
$开头的编号（如$1,$2），后续可以直接用这个编号引用该值，例如p $1 + 10。打印指针和数组：
(gdb) p ptr $3 = (int *) 0x0可以看到
ptr的值是0x0（NULL），这就是为什么解引用它会段错误。(gdb) p *data@5 $4 = {1, 2, 3, 4, 5}*data@5表示查看从data地址开始的5个整数。这对于查看数组内容非常方便。查看内存（examine）： 对于更底层的查看，可以使用
examine或x命令。它按照指定的格式和数量显示内存内容。 格式：x/[数量][格式][单位] 地址- 格式：
x(十六进制),d(十进制),u(无符号十进制),t(二进制),c(字符),s(字符串)等。 - 单位：
b(字节),h(半字，2字节),w(字，4字节),g(巨字，8字节)。
(gdb) x/5dw data 0x7fffffffe0a0: 1 2 3 4 5这条命令以十进制（d）字（w）为单位，显示从
data地址开始的5个元素。可以看到数组在内存中的布局。- 格式：
注意事项：
4. 控制程序执行：断点、单步与继续
让程序全速运行直到崩溃，往往不是最好的调试方式。我们需要更精细的控制，在关键位置暂停程序，这就是断点。
4.1 设置与管理断点（break）
在指定行设置断点：
(gdb) break 16 Breakpoint 1 at 0x5555555551f9: file buggy.c, line 16.这会在
buggy.c的第16行（printf语句）设置一个断点，编号为1。在函数入口设置断点：
(gdb) break faulty_sum Breakpoint 2 at 0x5555555551a9: file buggy.c, line 5.查看所有断点：
(gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00005555555551f9 in main at buggy.c:16 2 breakpoint keep y 0x00005555555551a9 in faulty_sum at buggy.c:5禁用/启用/删除断点：
(gdb) disable 1 # 禁用1号断点 (gdb) enable 1 # 启用1号断点 (gdb) delete 2 # 删除2号断点 (gdb) delete # 删除所有断点
4.2 条件断点
这是高级但极其有用的功能。你可以在断点上附加一个条件，只有条件为真时，程序才会在此暂停。
(gdb) break 7 if i == 3 Breakpoint 3 at 0x5555555551c1: file buggy.c, line 7.这会在buggy.c第7行（sum += array[i];）设置一个断点，但仅当循环变量i等于3时才触发。这对于调试循环中特定迭代的问题非常高效。
4.3 单步执行（step / next）
程序在断点处暂停后，你可以控制它如何继续执行。
step或s:步入。执行下一行源代码。如果下一行是一个函数调用，则会进入该函数内部。next或n:步过。执行下一行源代码。如果下一行是函数调用，则将该函数作为一个整体执行完，不会进入函数内部。finish:步出。继续执行，直到当前函数返回，然后暂停。continue或c:继续。从当前暂停点继续执行，直到遇到下一个断点、信号或程序结束。
让我们实际操作一下。先删除之前的断点，然后在faulty_sum函数入口和main函数开始处设置断点。
(gdb) delete (gdb) break main Breakpoint 1 at 0x5555555551e5: file buggy.c, line 13. (gdb) break faulty_sum Breakpoint 2 at 0x5555555551a9: file buggy.c, line 5. (gdb) run Starting program: /path/to/buggy Breakpoint 1, main () at buggy.c:13 13 int main() { (gdb) next # 步过 `int data[5] = ...` 这行 14 int data[5] = {1, 2, 3, 4, 5}; (gdb) next 15 int result = faulty_sum(data, 5);现在，下一行就要调用faulty_sum了。如果我们用next，会直接得到结果；如果用step，则会进入函数内部。我们选择step进去看看。
(gdb) step faulty_sum (array=0x7fffffffe0a0, len=5) at buggy.c:5 5 int sum = 0;成功进入了faulty_sum函数。现在，我们可以用next在这个函数里逐行执行，观察循环和变量的变化。
4.4 观察点（watch）——监控变量的变化
有时候，你不知道是哪里修改了某个关键变量。观察点可以让你在变量值被改变时自动暂停程序。
(gdb) watch sum Hardware watchpoint 3: sum设置了对变量sum的观察点。现在，每次sum的值被改变（比如sum += array[i]），GDB都会暂停，并告诉你旧值和新值。这对于追踪难以定位的变量修改非常有用。
实操心得：
step和next是调试中最常用的两个命令。一个简单的区分原则：当你想深入理解被调用函数的内部逻辑时，用step；当你确信被调用函数没问题，或者它是库函数（如printf），只想关注当前函数的流程时，用next。观察点对于调试多线程数据竞争或复杂状态机非常有效，但注意硬件观察点数量有限，可能受平台限制。
5. 回溯与上下文：当程序崩溃或卡住时
程序崩溃或陷入死循环时，仅仅知道当前行是不够的。你需要知道“我是怎么走到这一步的？”——这就是调用栈（Call Stack）的作用。
5.1 查看调用栈（backtrace）
backtrace或bt命令打印当前的函数调用栈。栈帧从下往上，展示了从main函数开始，到当前暂停位置的整个调用路径。
让我们重新运行程序，在段错误发生后立即输入bt：
(gdb) run Starting program: /path/to/buggy The sum is: 15 Uninitialized pointer value: Program received signal SIGSEGV, Segmentation fault. 0x0000555555555253 in main () at buggy.c:18 18 printf("Uninitialized pointer value: %d\n", *ptr); (gdb) bt #0 0x0000555555555253 in main () at buggy.c:18这个栈很简单，因为崩溃发生在main函数里。如果崩溃发生在一个深层嵌套的函数调用中，bt就能清晰地展示出完整的调用链，帮你快速定位问题源头。
5.2 切换栈帧与查看局部变量
调用栈中的每一层称为一个“栈帧”（Frame）。frame或f命令可以切换当前关注的栈帧，结合info locals可以查看该帧中的局部变量。
假设我们在一个更复杂的场景中，在faulty_sum函数内部暂停了。我们可以：
(gdb) bt #0 faulty_sum (array=0x7fffffffe0a0, len=5) at buggy.c:7 #1 0x00005555555551fe in main () at buggy.c:15 (gdb) frame 1 # 切换到 main 函数的栈帧（帧编号为1） (gdb) info locals data = {1, 2, 3, 4, 5} result = 0 ptr = 0x0这样，我们就能在faulty_sum内部调试时，随时查看调用者main函数里的变量状态。
5.3 调试已运行或崩溃的程序（attach / core dump）
附加到正在运行的进程：如果你的程序是一个长时间运行的服务（如网络服务器、守护进程），当它出现问题时，你可以用
attach命令将GDB“贴”到它的进程上。# 首先找到进程ID (PID) ps aux | grep my_server # 假设PID是 12345 gdb -p 12345 # 或者在GDB中 (gdb) attach 12345附加后，程序会暂停，你可以像调试普通程序一样设置断点、查看变量，然后用
continue让它继续运行。调试完后用detach分离。分析核心转储文件：当程序崩溃并显示
(core dumped)时，操作系统会生成一个核心转储文件（core dump），它是程序崩溃瞬间的完整内存镜像。结合带调试信息的可执行文件，GDB可以“复盘”崩溃现场。# 首先确保系统允许生成core文件 ulimit -c unlimited # 运行程序，使其崩溃生成core文件（通常名为 core 或 core.PID） ./buggy # 使用GDB加载可执行文件和core文件 gdb ./buggy coreGDB加载后，会直接停在程序崩溃的位置，并且所有变量、调用栈都保持着崩溃瞬间的状态。这是事后分析线上崩溃问题的利器。
踩坑记录：默认情况下，系统可能禁止生成core文件，或者core文件有大小限制。
ulimit -c unlimited只是临时生效。永久设置需要修改系统配置（如/etc/security/limits.conf）。另外，core文件可能很大，记得在测试环境操作，并关注磁盘空间。
6. 实战：排查“buggy.c”中的逻辑错误
现在，让我们运用所学，系统地排查buggy.c中的第一个问题：faulty_sum函数计算错误。虽然它输出了15（看起来正确），但循环条件i <= len存在越界风险。我们来验证一下。
首先，清理环境，重新开始调试：
gdb ./buggy (gdb) delete (gdb) break faulty_sum (gdb) run程序会在进入faulty_sum时暂停。
6.1 使用 display 自动显示变量
在循环调试中，反复输入print i和print sum很麻烦。display命令可以设置自动显示表达式，每次程序暂停时都会自动打印。
(gdb) display i 1: i = 0 (gdb) display sum 2: sum = 0 (gdb) display array[i] 3: array[i] = 16.2 单步执行并观察越界
现在，我们使用next命令逐行执行循环体，观察display的信息。
(gdb) next # 执行 int sum = 0; 6 for (int i = 0; i <= len; i++) { 1: i = 0 2: sum = 0 3: array[i] = 1 (gdb) next # 执行 i++ 和循环条件判断，进入第一次循环 7 sum += array[i]; 1: i = 0 2: sum = 0 3: array[i] = 1 (gdb) next # 执行 sum += array[i]; 6 for (int i = 0; i <= len; i++) { 1: i = 0 2: sum = 1 3: array[i] = 1继续按next，你会看到i从0递增到5，sum累加到15。关键来了，当i=5时：
1: i = 5 2: sum = 15 3: array[i] = 0注意array[i]的值！当i=5时，array[5]已经超出了data数组（下标0-4）的范围。我们打印的0实际上是紧邻数组之后的一块内存的内容，这是典型的缓冲区溢出访问。虽然这次碰巧是0，没有导致立即崩溃，但这是极其危险的行为，可能破坏其他数据，导致不可预知的后果。
继续执行，当i变成6时，循环条件i <= len(6 <= 5) 为假，循环结束。函数返回了15。
6.3 验证数组边界
我们可以直接打印数组的地址和越界地址来加深理解。
(gdb) p &array[0] $5 = (int *) 0x7fffffffe0a0 (gdb) p &array[4] $6 = (int *) 0x7fffffffe0b0 (gdb) p &array[5] $7 = (int *) 0x7fffffffe0b4计算一下：&array[4]是0x7fffffffe0b0，&array[5]是0x7fffffffe0b4，相差4字节（一个int的大小）。array[5]这个地址已经不属于data数组了。
通过这个简单的调试过程，我们不仅确认了bug的存在（循环条件错误），还亲眼看到了越界访问的具体内存内容。这就是GDB的价值：它将抽象的逻辑错误，变成了可视化的、确定的内存操作。
7. 高级技巧与常用命令速查
掌握了基础，一些高级技巧能让你事半功倍。
7.1 直接修改变量与跳转执行
GDB允许你在调试时动态修改程序状态，这在测试特定场景时非常有用。
修改变量：
set variable var = value(gdb) set variable i = 0 # 将循环变量i重置为0 (gdb) set variable ptr = &data[0] # 给危险的ptr赋一个合法地址修改后，程序可以继续执行，仿佛这个值从一开始就是那样。这可以用来绕过某些条件，测试不同分支。
跳转执行：
jump location(gdb) jump 19 # 跳转到第19行（return 0;）这会让程序直接从当前执行点跳到指定行继续执行，跳过中间的代码。警告：跳转可能破坏栈平衡和变量状态，需谨慎使用，主要用于极端测试。
7.2 反汇编与寄存器查看
当问题深入到汇编层面，或者没有源代码时（如调试库函数），你需要查看汇编指令。
disassemble或disas: 反汇编当前函数。disas /m: 混合显示源代码和汇编代码。info registers或i r: 查看所有寄存器的当前值。p $rax: 查看特定寄存器（如rax）的值。
7.3 自定义命令与初始化文件
如果你有一系列固定的GDB命令（如设置特定断点、显示特定变量），可以将其写入一个文件（如.gdbinit），GDB启动时会自动执行。
# 文件内容示例 .gdbinit break main break faulty_sum display i display sum run也可以在GDB会话中使用source命令加载脚本文件。
7.4 常用命令速查表
| 命令 | 简写 | 用途说明 |
|---|---|---|
run [args] | r | 运行程序，可带参数 |
break [location] | b | 在指定位置（行号/函数名）设置断点 |
break [location] if [condition] | 设置条件断点 | |
continue | c | 继续运行直到下一个断点 |
step | s | 单步步入（进入函数） |
next | n | 单步步过（不进入函数） |
finish | fin | 执行完当前函数并暂停 |
print [expr] | p | 打印表达式或变量的值 |
display [expr] | disp | 每次暂停时自动打印表达式 |
backtrace | bt | 打印函数调用栈 |
frame [num] | f | 切换到指定栈帧 |
info breakpoints | i b | 查看所有断点信息 |
info locals | i loc | 查看当前栈帧的局部变量 |
watch [expr] | 设置观察点（变量改变时暂停） | |
list | l | 显示源代码 |
quit | q | 退出GDB |
8. 从GDB命令行到图形化与集成环境
虽然命令行GDB功能强大，但现代IDE提供了更直观的图形化调试界面，底层其实都调用了GDB。
- VSCode：安装C/C++扩展后，配置
launch.json，可以设置断点、查看变量、调用栈，所有操作通过点击完成，体验流畅。 - CLion / QtCreator：作为专业的C++ IDE，提供了极其完善的图形化调试支持，包括内存视图、表达式求值、多线程调试等。
- GDB的文本用户界面（TUI）：GDB自身也提供了一个简单的文本图形模式，输入
gdb -tui ./buggy或 在GDB中按Ctrl+X+A开启。它会分屏显示源代码、汇编和命令窗口。
对于新手，我建议从命令行GDB开始。图形化界面确实方便，但理解每一步背后的命令（next,step,print,break）能让你建立更扎实的调试思维。当你熟悉了这些概念，再切换到任何图形化工具都会易如反掌，因为你知道每个按钮背后发生了什么。
调试是一门实践性极强的技能。最好的学习方式就是把你自己的、或者找到的有bug的程序，用GDB从头到尾跟一遍。开始时可能会觉得命令生疏，但调试过三五个程序后，这些命令就会成为你的肌肉记忆。记住，每个优秀的程序员都是优秀的调试员，而GDB，就是你成为调试高手路上最可靠的伙伴。