调试版编译必须配对使用 -o0 -g，否则gcc 14默认优化会破坏调试信息；还需禁用lto、确保dwarf版本兼容（如-gdwarf-4）、静态/动态库也需带-g，并验证二进制含完整debug段。
调试版编译必须加 -g，但光加它不够
只写 gcc -g -o app app.c 很可能让你在 GDB 里看不到变量、断点跳过、甚至进不了函数。GCC 14 默认启用的优化会删掉调试所需的信息，-g 本身不压制优化。
-
-O0是强制关闭所有优化的开关，和-g必须成对出现 - 如果用了
-fno-omit-frame-pointer，GDB 的调用栈会更准（尤其在内联或尾调用场景） - 避免混用
-O2 -g或-O3 -g—— 这不是“带调试信息的优化版”，而是“调试信息残缺的优化版”
-O0 -g 编译后，GDB 仍无法显示变量？检查 DWARF 版本
GCC 14 默认生成 DWARF5，但老旧 GDB（如 8.0 以下）解析不稳定，常表现为 Cannot find bounds of current function 或变量值显示为 <optimized out></optimized>。
- 用
readelf -wi app | head -5看输出里是否含DW_TAG_compile_unit和DW_AT_dwarf_version值为 5 - 降级到 DWARF4：编译时加
-gdwarf-4，即gcc -O0 -gdwarf-4 -o app app.c - 验证是否生效：
readelf -wi app | grep dwarf_version应输出4
链接阶段破坏调试符号？警惕 -flto 和静态库
启用 LTO（Link-Time Optimization）会让 GCC 在链接时重写中间表示，原始行号、变量名映射全部丢失，GDB 只能显示汇编或空栈帧。
- 调试期间务必禁用 LTO：
-fno-lto（不是--no-lto） - 静态库（
.a）若未用-g编译，链接后调试信息就不可追溯 —— 制作静态库时也要加-g：gcc -c -g add.c -o add.o && ar rcs libmath.a add.o - 动态库（
.so）同理，编译时加-g，链接时不加-static
VS Code 调试失败？别只改 launch.json
很多用户以为配好 launch.json 就万事大吉，但底层可执行文件没带调试信息，再好的配置也白搭。
- 确认二进制文件含调试段：
file app输出应含with debug_info；size app显示.debug_*段非零 - VS Code 的
miDebuggerPath要指向真实 GDB（如/usr/bin/gdb），不是gdb-multiarch或包装脚本 - 如果项目含预编译头（
.gch），确保它也是-g -O0编译的，否则源码与调试信息错位
gcc 命令开始就要控制每个环节：优化关掉、DWARF 版本对齐、LTO 关掉、静态库带 -g、二进制验证到位——漏掉任意一环，GDB 都可能给你摆烂。
