必须加 -g 编译，否则 GDB 无法加载符号表，导致 list 报“No symbol table”、print 报“Can’t find symbol”；调试需用 -O0 关闭优化，多线程崩溃时应配合 info threads 与 thread apply all bt 全面分析。
编译时必须加 -g，否则 GDB 看不到符号信息
不带调试信息的二进制文件，GDB 只能看汇编、不能查变量、不能设源码断点。常见错误是直接 g++ main.cpp -o app，结果 gdb ./app 里用 list 显示 “No symbol table is loaded”，print x 报错 “Can’t find symbol”。必须显式加上 -g：g++ -g -o app main.cpp。GCC 还支持 -g3（包含宏定义），但日常调试 -g 足够。
在 main 入口前打断点，用 start 或 break _start
想观察程序刚启动时的状态（比如全局对象构造、静态初始化），不能只 break main——此时很多初始化已完成。正确做法是：start 命令（GDB 7.0+）会自动停在 main 第一行之前；或手动 break _start（ELF 入口），再 run。注意：_start 是汇编入口，需配合 stepi 单步指令级执行，next/step 会跳过 libc 初始化逻辑。
print 查变量失败？检查作用域和优化级别
常见现象：print vec.size() 返回 “Cannot evaluate function — undefined symbol”，或 print local_var 提示 “No symbol in current context”。原因有三：g++ -O2 优化可能内联/删除变量；断点停在函数外却尝试打印局部变量；变量名被模板/匿名命名空间修饰（可用 info variables 模糊搜索）。解决方法：编译加 -O0（关闭优化）；确保在对应栈帧（frame 或 up/down 切换）；对 STL 容器，优先用 print vec 而非 vec.size()（避免调用函数）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
调试多线程崩溃时，info threads 和 thread apply all bt 必须连用
段错误发生后，GDB 默认只显示当前线程栈，容易漏掉真正出问题的线程。先运行 info threads 看所有线程 ID 和状态（* 1 表示当前），再用 thread 3 切到可疑线程，bt 查栈；更高效的是 thread apply all bt 一次性打印全部线程回溯。注意：如果崩溃时某线程正持有锁，其他线程可能卡在 futex_wait，这时要重点看标记为 running 或 stopped 的线程，而非全是 sleeping 的。
立即学习“C++免费学习笔记（深入）”；
GDB 调试真正的难点不在命令本身，而在理解程序实际执行路径与符号表的映射关系——尤其是涉及内联、模板实例化、动态链接库时，info symbol 和 set debug symbols on 这类诊断命令比断点更常被忽略。
