根本原因是编译器优化将局部变量存入寄存器或彻底消除；必须使用-O0 -g3 -fno-omit-frame-pointer -fno-lto才能确保变量可查、调用栈完整、断点稳定。

变量显示 <optimized out> 的根本原因

这不是 GDB 的问题，而是编译器在优化时把局部变量直接放进寄存器、甚至整个消除掉了。典型触发条件是用了 -O2 或更高优化等级，哪怕加了 -g，调试信息里也找不到该变量的存储位置。GDB 没法凭空“恢复”一个不存在的栈内存地址。

调试阶段必须禁用的编译选项

想让变量可查、调用栈完整、断点稳定命中，就得让编译器“说实话”。这些选项不是可选，是底线：

• -O0：彻底关闭优化，确保每个变量都有对应栈槽或明确寄存器绑定
• -fno-omit-frame-pointer：强制保留 %rbp（x86_64）或 fp（ARM），否则 backtrace 会断链
• -g3：比 -g 多带宏定义、内联展开等元信息，对复杂作用域更友好
• -fno-lto：链接时优化（LTO）会打乱函数边界和行号映射，bt full 可能跳到错误行

已经用 -O2 -g 编译了，还能补救吗？

基本不能。优化后的代码已丢失变量生命周期信息，DWARF 符号里没有对应描述，GDB 无从还原。但你可以做两件事止损：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 用 info registers 查看当前寄存器值，有些变量在优化后仍暂存在 %rax、%rdi 等寄存器中（需结合汇编确认）
• 用 disassemble /m 对照源码行与汇编，手动推导变量可能所在寄存器或栈偏移
• 立刻重建调试版：重新编译时严格使用 -O0 -g3 -fno-omit-frame-pointer，别再混用优化和调试

为什么 bt full 有时也看不到变量？

因为 bt full 依赖每个栈帧里保存的变量调试信息。如果某一层函数被内联（inline 或 -finline-functions）、或用了 -O2 后变量被提升为 SSA 形式并消去，那一帧的局部变量表就是空的。这不是命令没用，是信息从源头就没了。

真正可靠的调试起点，永远是未优化的二进制——其余都是在残缺信息上拼图。