编译调试选项：-g 选项的作用、优化级别对调试的影响

说实话，我见过太多程序员在调试时抓耳挠腮，最后发现是编译选项没配对。今天咱们就来聊聊这个看似基础、实则坑多的话题。

-g 选项到底在干什么？

简单说，-g 就是告诉编译器：「嘿，帮我保留调试信息」。这些信息包括：

• 源代码行号与机器码的对应关系
• 变量名、类型、作用域信息
• 函数名、参数列表、栈帧布局
• 宏定义、结构体定义等类型信息

没有 -g，GDB 就像瞎子摸象。你只能看到一堆汇编指令，根本不知道当前执行到哪一行代码。

优化级别对调试的影响

这里有个常见的误区：很多人觉得加了 -g 就万事大吉了。其实不然，优化级别才是真正的「杀手」。

GCC 的优化级别从 -O0 到 -O3，还有 -Os（优化体积）。我列个表，你一看就明白：

为什么会这样？因为优化器会做很多「聪明」的事：

• 变量可能被优化掉，直接存在寄存器里
• 代码顺序可能被重排，你看到的行号跟实际执行顺序对不上
• 函数可能被内联，调用栈变得面目全非
• 循环可能被展开，单步调试时跳来跳去

-O0 与 -g 的黄金搭档

我个人习惯，开发调试阶段永远用 -O0 -g。这两个选项配合起来，效果是这样的：

gcc -O0 -g -o myapp myapp.c

为什么说它们是黄金搭档？

• -O0 保证代码不被优化，变量、函数、执行流都保持原样
• -g 提供完整的调试符号表
• 两者结合，GDB 能精确告诉你每一行代码对应的机器指令

你想想看，调试时最怕什么？最怕「这里明明应该执行了，但 GDB 告诉我跳过去了」。这就是优化搞的鬼。-O0 就是用来杜绝这种问题的。

gcc -O2 -c module_a.c
gcc -O0 -g -c module_b.c
gcc -o myapp module_a.o module_b.o

strip 命令与调试符号

说到调试符号，就不得不提 strip 命令。它的作用很简单：从可执行文件里删掉调试信息。

为什么要删？因为调试信息占空间啊。一个带 -g 编译的程序，体积可能是不带 -g 的 5-10 倍。生产环境部署时，没人愿意把几百兆的调试信息也带上去。

# 查看文件大小
$ ls -lh myapp
-rwxr-xr-x 1 user user 12M myapp

# strip 之后
$ strip myapp
$ ls -lh myapp
-rwxr-xr-x 1 user user 2.1M myapp

看到没？从 12M 缩到了 2.1M。这就是调试信息的重量。

但要注意，strip 是不可逆的。一旦删了，就再也找不回来了。所以我的做法是：

1. 开发机保留带 -g 的版本
2. 发布时用 strip 生成瘦身版
3. 同时保留一份带调试符号的版本，用于事后分析 core dump

知识体系总览

下面这张图，把今天讲的内容串起来了：

嗯，这张图把今天的内容都概括了。你仔细看看，核心就是那条黄金法则：开发调试用 -O0 -g，发布部署前用 strip 瘦身。

实战建议

最后，我根据多年经验，给你几条实在的建议：

• Makefile 里区分 debug 和 release 配置：debug 用 -O0 -g，release 用 -O2 加 strip
• 保留一份带调试符号的版本：万一线上 core dump，你还能分析
• 别在生产环境用 -O0：性能差太多，而且暴露的信息太多，有安全风险
• 调试第三方库时：确保它们也是用 -g 编译的，否则你只能看到一堆问号

好了，关于编译调试选项，今天就聊到这儿。记住，调试信息是你的朋友，别把它弄丢了。