在 gcc 中使用 -g 和 -O2 选项
有人经历过将 -g （调试符号）和 -O2 （最佳安全优化）与 gcc 编译器混合使用吗？
我必须调试分发给最终用户的发布程序的崩溃，该程序可能会将核心文件发回给我。
我一直习惯于调用：
gdb <<我的程序>> <<核心文件>>
看看问题出在哪里。现在我只能看到调用跟踪，但没有调试符号，我遇到了麻烦。
有什么想法吗？
Does anybody experience mixing -g (debugging symbols) and -O2 (best safe optimization) with gcc compiler?
I have to debug crashes of a release program distributed to final users that could send me back the core file.
I've always used to call:
gdb << myprogram >> << core file >>
and see where the trouble is. Now I can just see the call-trace but having no debugging symbols I'm quite in trouble.
Any idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
效果很好。
或者，由于优化，有时您使用调试器单步执行的源代码与源代码并不完全匹配，但恕我直言，尽管有调试符号使调试变得更加容易。
It works fine.
Or well, due to the optimization sometimes the source you're stepping through with the debugger doesn't match up exactly with the source, but IMHO despite this having the debug symbols makes debugging much easier.
我们在生产环境中同时使用两者，如果客户只遇到过一次崩溃，那么调试会变得更加容易。它可以让您很好地了解问题所在（而不是内存损坏）。
理论上，添加 -g 不会真正影响性能，尽管可执行文件会变大。在嵌入式环境中，这是一个很大的权衡。
We use both together in production environment, which makes debugging a lot easier if the customer have only seen a crash once. It gives you a pretty good idea where the problem is (not if it was a memory corruption).
In theory adding -g shouldn't really affect the performance, although the executable gets large. In embedded environment it is a big trade-off.