断点不命中主要因编译优化导致，必须使用-o0 -g组合：-o2等优化会消除变量、重排语句、内联函数，使源码与执行流脱节；dwarf版本不匹配、lto启用或预编译头缺失调试信息也会加剧问题。
断点不命中？大概率是优化在捣鬼。必须用 -O0，其他选项都靠边站。
为什么 -O2 + -g 会让断点失效
GCC 在 -O2 下会做跨函数标量替换、死代码消除、变量提升到寄存器等操作——这意味着你源码里写的 int i = 0; 可能根本不会在内存中分配空间，GDB 就无法在那行设断点，甚至显示 <optimized out></optimized>。
-
-O2会重排语句顺序，导致 GDB 的行号映射错位 - 循环可能被展开或内联，原始
for行消失 - 局部变量若未被取地址，大概率被完全优化掉
-O0 -g 是调试阶段唯一安全的组合
这不是“推荐”，而是硬性要求：只有 -O0 才保证每行源码对应一条可停顿的指令，每个变量真实存在于栈上。
- 编译命令必须写成：
gcc -O0 -g -o program program.c - 别混用
-O2 -g或-O3 -g——哪怕只是想“顺便看看性能”，也会破坏调试可信度 - 如果项目用了 Makefile，确保
CFLAGS在 debug target 中显式覆盖为-O0 -g
容易被忽略的连带陷阱
就算写了 -O0 -g，也可能因其他参数被悄悄抵消：
-
-flto（链接时优化）会重构中间表示，让-O0失效；必须加-fno-lto - 用了预编译头（
.gch）但没给它也加-g和-O0，会导致头文件部分调试信息错乱 - 某些构建系统（如 CMake）默认启用
-DNDEBUG，它可能间接触发宏定义相关的优化分支，需检查是否干扰了关键逻辑路径
DWARF 版本不匹配也会让断点“看起来设上了，实际不触发”
GCC 14 默认生成 DWARF5，但老版本 GDB（比如 gdb 8.0 之前）解析不全，尤其在行号表（.debug_line）缺失时，GDB 根本找不到断点对应地址。
- 验证当前二进制用的格式：
readelf -wi program | head -5，看是否有DW_TAG_compile_unit和DW_AT_stmt_list - 降级兼容：加
-gdwarf-4替代默认-g，即用gcc -O0 -gdwarf-4 -o program program.c - RISC-V 等嵌入式场景更敏感，务必搭配
-Og（专为调试设计的轻量优化）而非-O2
真正麻烦的不是设不上断点，而是断点设上了却悄无声息地跳过——那通常意味着调试信息和执行流之间已经脱节，得从编译参数一层层往回查。
