GDB 调试实战手册
GDB (GNU Debugger) 是 Linux 环境下程序开发者的“手术刀”。无论是初学者的逻辑错误，还是生产环境下的内存崩溃，掌握 GDB 都能让你事半功倍。
一、 编译准备：注入“灵魂”
在使用 GDB 调试前，必须在编译时保留符号表信息。
- 关键参数：使用
-g 选项。
- 示例：
gcc -g main.c -o my_program
如果没有 -g，你在调试时将看不到源码，只能看到晦涩的汇编指令。
二、 基础调试：交互式指令
启动调试：gdb ./my_program
1. 运行与断点
l (list)：查看源码。b (break)：设置断点。可以是行号 b 10，也可以是函数名 b main。r (run)：开始运行程序。n (next)：单步执行（不进入函数内部）。s (step)：跳进执行（进入函数内部）。
2. 查看状态
p (print)：打印变量值，例如 p my_var。display：跟踪变量。设置后，每次程序停下都会自动显示该变量的值。bt (backtrace)：查看调用栈，程序崩溃时的“第一现场”记录。
三、 自动化调试：批处理模式
在 CI/CD 流水线或自动化测试中，手动输入命令是不现实的。这时可以使用 GDB 的 批处理模式。
核心命令
gdb -batch -ex "run" -ex "bt" ./my_program
参数详解：
-batch：运行完指定命令后立即退出，不进入交互界面。-ex (execute)：在启动后执行随后的指令。可以组合多个 -ex 形成指令链。run：让程序跑起来。bt：如果程序中途崩溃，立即打印出堆栈信息。
进阶场景应用：
- 保存崩溃报告：
gdb -batch -ex "run" -ex "bt" ./my_program > error_log.txt 2>&1
- 多线程排查：
使用 thread apply all bt 打印所有线程的堆栈，防止死锁分析时遗漏。
- 深度取证：
使用 bt full 打印堆栈的同时输出各层函数的局部变量值，极大提高定位效率。
四、 核心转储 (Core Dump) 调试
当程序在生产环境“悄悄”崩溃时，我们可以通过 Core 文件进行事后分析。
- 开启 Core 限制：执行
ulimit -c unlimited（允许系统生成 core 文件）。
- 加载现场：
gdb -batch -ex "bt" ./my_program core
这条命令会直接读取 core 文件并输出崩溃位置，无需重新运行程序。
五、 调试进阶小贴士
- 条件断点：
b 20 if i == 500。当循环次数很大时，这能帮你直接跳到出问题的那一次。
- 监视点 (Watchpoint)：
watch some_var。当变量值被修改时程序自动停下，这是排查“谁动了我的内存”的神器。
- TUI 界面：在 GDB 中按下
Ctrl + X + A。它会开启一个分屏界面，上方显示源码，下方输入指令，体验接近图形化调试器。
总结
- 日常开发：使用交互式命令（
b, n, p）观察逻辑。
- 线上排查：使用
Core Dump 还原事故现场。
- 自动化/脚本：使用
-batch -ex 实现无人值守的故障捕获。
掌握了这些，你就能在 Linux C/C++ 开发中游刃有余地应对各类 Bug。