编译优化时调试信息不见了？别急，先看看这几种情况
最近有个同事在改一个 C++ 项目，代码跑起来不对劲，想用 gdb 调试一下，结果发现断点打不上，变量也看不到值。他一头雾水：不是加了 -g 编译选项吗？怎么没符号表？
查了一圈才发现，问题出在编译优化上。虽然加了 -g，但开启了 -O2 或更高的优化级别，某些情况下调试信息被优化掉了，尤其是局部变量、函数调用栈这些关键内容。
为什么优化会干掉调试信息？
编译器做优化的时候，为了提升性能，会进行内联函数、删除未使用变量、重排指令等操作。比如你写了一个小函数，编译器觉得直接展开更高效，就会把它 inline 掉。这时候你在源码里下断点，实际执行的代码已经不存在了，自然就停不下来。
还有些变量可能被优化到寄存器里，或者因为“死代码消除”被整个删掉。调试器找不到对应的内存位置，也就显示不了值。
如何确认是不是优化导致的？
最简单的办法是临时关掉优化，只保留 -g，重新编译试试。
g++ -g -O0 main.cpp -o main注意这里用的是 -O0，表示关闭所有优化。如果这时候能正常调试，那基本可以确定是优化惹的祸。
不想牺牲性能，还能保留调试信息吗？
可以。GCC 和 Clang 都提供了一些折中方案。比如加上 -fno-omit-frame-pointer，能帮助还原调用栈：
g++ -g -O2 -fno-omit-frame-pointer main.cpp -o main再比如用 -fvar-tracking-only，可以让编译器保留更多变量轨迹，虽然会增加一点编译时间和体积，但对运行性能影响不大。
还有一个实用技巧：在关键函数上禁用优化，其他地方照常优化。用 GCC 的 attribute 就能实现：
__attribute__((optimize("O0")))
void debug_me() {
int tmp = calc_value();
printf("tmp = %d\n", tmp);
}这样只有这个函数不优化，不影响整体性能，又能安心调试。
发布版本要不要留调试信息？
线上环境通常不会带完整的调试信息，一是体积大，二是有泄露代码结构的风险。但建议生成并保存对应的 .debug 文件或使用 strip 分离符号表。万一线上出问题，可以用它来还原堆栈。
比如编译后执行：
strip --only-keep-debug main -o main.debug
strip --strip-debug main出问题时把 core dump 和 main.debug 一起拿过来，照样能定位到具体代码行。
调试和优化本不该对立，关键是搞清楚它们之间的摩擦点。有时候一点点编译参数的调整，就能省下半天瞎猜的时间。