C++怎么使用gdb调试_C++调试工具教程【排错】

gdb 的核心是“遇问题才真正开始用”，需编译时加 -g 和 -o0，断点要设在可执行语句且避免优化干扰，多线程调试需手动控制线程行为。

gdb 不是“学完就能用”，而是“遇到问题才真正开始用”——它不帮你写代码，但能让你看清代码到底在干什么。

怎么启动 gdb 并加载可执行文件

关键不是“怎么进 gdb”，而是“为什么进不去”或“进去后没符号”。常见错误是直接 gdb ./myapp 却发现 print var 报错 No symbol "var" in current context，这几乎 100% 是编译时没加 -g。

• 必须用 g++ -g -O0 myapp.cpp -o myapp 编译（-O0 防止优化导致变量被删/重排）
• 如果程序带参数，别在 gdb 外传：用 gdb ./myapp 启动后，再用 run --input data.txt
• core dump 文件要配合原二进制：gdb ./myapp core.1234，否则堆栈全是问号

断点设在哪、什么时候生效

断点不是越多越好，设错位置反而浪费时间。比如在内联函数里下断，或者对已优化掉的函数名下断，gdb 会静默忽略，还假装停住了。

• 函数入口断点：用 break main 或 break MyClass::doWork —— 注意类名和作用域符不能少
• 某行断点：break myapp.cpp:42，但前提是该行有可执行语句（空行、注释、声明都不行）
• 条件断点慎用：break vector.h:123 if i == 5 可能因内联或优化失效；优先用 watch 监视变量变化
• 临时断点只触发一次：tbreak，适合确认某段逻辑是否真走到

查看变量值总显示 <optimized out></optimized>

这不是 gdb 的 bug，是编译器在告诉你：“这段代码我重写了，你看到的变量名已经不存在了”。哪怕加了 -g，只要开了 -O1 及以上，就大概率中招。

立即学习“C++免费学习笔记（深入）”；

• 最可靠解法：重新编译，明确指定 -O0 -g
• 临时绕过：用 info registers 看寄存器，或 x/4xw $rbp-8 手动查栈帧（需懂汇编基础）
• print 某指针时显示地址但内容为空？先 print *ptr 解引用，再确认 ptr 是否为 nullptr
• STL 容器（如 std::vector）变量默认只显示 size/capacity，要展开得用 print v._M_impl._M_start（GCC libstdc++ 内部字段），不同标准库实现字段名不同

调试多线程时为什么停不住、切不对线程

默认情况下，gdb 只在主线程中断，其他线程继续跑，你看到的堆栈可能瞬间就变了。更糟的是，next 或 step 可能跨线程跳转，根本不是你想要的逻辑流。

• 启动时加 --ex "set follow-fork-mode child" 跟子进程，多线程程序通常需要这个
• 查看线程列表：info Threads，当前线程前有 *；切换用 thread 2
• 让所有线程都停在断点：set scheduler-locking on（慎用，可能掩盖竞态）
• 想只在某线程下断点：break myfunc thread 3，避免干扰其他线程执行路径

真实调试里，最难的不是命令记不全，而是分不清“程序没按你想的走”，还是“你根本没看清它实际怎么走”。gdb 显示的每一行汇编、每一个寄存器值，都是证据，不是装饰。