Question

我见过的大多数构建环境至少有两种策略：调试构建与最终/优化/发布构建。使用gcc，这通常意味着某些版本的-g vs -O。现在，我发现使用-O3构建优化构建的情况，而调试版本使用-g3 和 -O3构建。 man gcc确实表明这是可能的，但这对我来说似乎违反了实际的调试目的。

审核http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html提醒我-Og，它允许不干扰调试的优化。这对我来说很有意义，但除非你基本上试图调试gcc自己的优化能力，否则有什么令人信服的理由可以调试-O3 -g3？

Answer 1

有时人们会编写错误的代码 - 例如，可能导致未定义行为的代码。现在让我们假设未定义的行为在低优化或无优化的情况下似乎“正确”工作，但它会导致-O3的灾难性崩溃。您将要在-O3调试此问题，对吧？那么你别无选择，只能添加-g标志并前往城镇，即使调试经验可能会受到优化的影响。

一般来说，构建系统将“调试/释放”轴与“优化/未优化”轴相混合存在一个大问题。实际上，它们应该是正交的 - 例如，通常需要使用日志记录进行“调试”构建，但仍然可以在启用优化的情况下快速运行。同样，在优化构建中没有可用的调试符号的情况下，跟踪与优化器相关的错误可能非常困难。

                  +--------------------------------+
                  |           Optimizations        |
                  +-----------------+--------------+
                  |        On       |     Off      |
 +---------+------+-----------------+--------------+
 |         |  On  | Debug optimized |  Best debug  |
 |  Debug  |      |    code         |  experience  |
 | Symbols +------+-----------------+--------------+
 |         |  Off |   Release build | Probably not |
 |         |      |  for customers  |    useful    |
 +---------+------+-----------------+--------------+

使用-g3和-O3进行编译

1 个答案: