GDB调试C++程序的核心是编译时加-g生成DWARF符号表，否则断点不命中、变量显示为空；必须避免-O2以上优化，推荐CMake中使用Debug模式（-g -O0）；断点需确保函数名/路径正确，变量不可见多因被优化，可用volatile临时规避。
直接上结论：GDB 调试 C++ 程序，核心是编译时加 -g，运行时用 gdb ./a.out，下断点靠 break，单步靠 next 和 step，看变量用 print —— 但漏掉 -g 或没处理符号表路径，90% 的断点会“不命中”或显示
编译必须带 -g，且避免 -O2 以上优化
没有调试信息，GDB 就像盲人摸象。C++ 源码和机器指令之间靠 DWARF 符号表关联，而 -g 是生成它的开关。
-
g++ -g -o main main.cpp✅ 正确：保留完整符号与行号映射 -
g++ -O2 -g main.cpp⚠️ 危险：内联、寄存器复用会导致变量显示 -
g++ -o main main.cpp❌ 失效：GDB 启动后list显示“No symbol table is loaded”，break main会提示“Function not defined”
如果项目用 CMake，确认 CMAKE_BUILD_TYPE 是 Debug（自动加 -g -O0），而不是 Release。
break 下断点的三种常见写法及失效原因
断点下不对，不是 GDB 问题，大概率是符号没加载或位置写错。
立即学习“C++免费学习笔记（深入）”；
-
break main：在main函数入口设断 —— 要求函数名可识别（未被模板实例化名污染，未被inline消除） -
break filename.cpp:15：按行号下断 —— 文件名必须和编译时路径一致；若源码在/home/user/proj/src/，但编译命令在/tmp下执行，GDB 可能找不到该路径下的filename.cpp -
break ClassName::methodName：对成员函数有效，但需确保类定义已加载（比如头文件没被预编译或模板未实例化）
下完断点后，用 info breakpoints 确认状态是 y（enabled），不是 n（disabled）或 pending（未解析）。出现 pending 通常意味着函数还没加载（比如动态库中函数，尚未 dlopen）。
调试时变量显示
这不是 GDB 报错，而是编译器把变量优化掉了 —— 寄存器里没它，栈上也没预留空间，GDB 真的“看不见”。
- 立刻检查编译参数：运行
readelf -wi ./a.out | head -n 20，看到DW_TAG_variable才说明变量符号存在；若无，就是没加-g或被优化抹除了 - 临时补救：在可疑变量前加
volatile（如volatile int x = 42;），阻止编译器优化掉读写 - 调试阶段别用
-O3；-O1有时还能保留部分变量，但不如-O0可靠
注意：std::string、std::vector 这类对象即使未被优化，也可能因内部指针间接性导致 print 显示不直观，此时用 print v._M_impl._M_start（GCC libstdc++）或 print v._M_dataplus._M_p 查底层数据更直接。
多线程下 step 和 next 行为差异
GDB 默认只控制当前线程。你用 next 单步，其他线程仍在跑 —— 可能导致竞态被掩盖，或断点停在非预期线程。
-
next：执行下一行源码（不进入函数），但仅限当前线程；其他线程继续运行 -
step：进入函数调用，同样只作用于当前线程 - 想暂停所有线程：先
info threads查线程 ID，再thread apply all interrupt；或者启动时加set follow-fork-mode parent+set schedule-multiple on让 GDB 尽量同步调度
真实场景中，pthread_create 后立刻 step，很可能跳过新线程的初始化逻辑 —— 因为新线程还没真正开始执行。这时更适合用 break 在新线程函数入口处硬设断点。
最常被忽略的一点：GDB 不读取 .gdbinit 除非显式启用或放在家目录；调试时临时定义的命令（如 define pvec）不会跨 session 保存。真要提升效率，得配好 ~/.gdbinit 并确认 show auto-load scripts 是 on。
