<optimized out> 表示变量被编译器优化移除，寄存器或栈中无对应存储；多见于 -O2/-O3 编译，因 -g 仅保留符号表不阻止优化；-O0 -g 可确保变量可见，-Og -g 是兼顾调试与性能的推荐折中方案。
gdb里看到<optimized out>就说明变量被优化掉了
这不是GDB“判断”出来的，而是它明确告诉你：这个变量在编译时被优化器移除了，寄存器或栈上已无对应存储位置。你无法读取它的值，print会直接显示<optimized out>，info locals里也看不到它。
为什么<optimized out>只出现在-O2/-O3编译的程序里
编译器在-O2及以上级别会 aggressively 把局部变量放进寄存器、合并计算、甚至整个删掉冗余变量。而-g只是告诉编译器“保留调试信息”，但不阻止优化逻辑本身——所以符号表里还记着变量名，实际运行时却没地方存它了。
-
-O0 -g：最安全，所有变量都可查，但性能差，适合纯调试 -
-Og -g：GCC推荐的折中方案，开启不影响调试的轻量优化，大部分变量仍可见 -
-O2 -g或更高：变量消失概率高，尤其循环计数器、临时中间值、未被后续使用的返回值
怎么确认是不是真被优化，而不是路径/符号问题
先排除常见干扰项，再下结论：
- 用
file <binary>确认可执行文件确实含调试信息（输出含with debug_info） - 用
readelf -S <binary> | grep debug检查.debug_*节存在 - 用
gdb <binary> <core>后立即执行bt full，看崩溃帧里哪些变量标了<optimized out>；如果连函数参数或main里的简单int x = 42;都这样，基本就是优化导致 - 别信
info registers——寄存器内容不等于变量值，优化后寄存器可能复用、重命名，GDB无法映射回源码变量名
遇到<optimized out>还能做什么
不能读值，但仍有线索可挖：
- 用
disassemble看崩溃点附近的汇编，结合x/10i $pc观察指令在操作哪些寄存器或内存地址 - 用
info registers查$rax、$rdi等是否为0或明显非法值（比如0x0常暗示空指针） - 用
x/4xw <addr>手动查看疑似变量所在的栈偏移（需从汇编推断栈帧布局） - 最关键的：换用
-Og -g重新编译，复现问题——这才是定位根源的正解，不是硬啃优化后的core
真正棘手的从来不是<optimized out>本身，而是团队把-O2 -g当“兼顾调试和性能”的默认选项，结果每次core都要靠猜。优化和调试本就互斥，接受这点，比在GDB里徒劳print更省时间。
