4

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

查看http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html让我想起了-Og，它允许优化不干扰调试。这对我来说是有道理的，但是-O3 -g3除非你基本上是在尝试调试 gcc 自己的优化能力，否则有什么令人信服的理由来调试呢？

4

1 回答 1

9

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

将“调试/发布”轴与“优化/未优化”轴混为一谈的构建系统通常存在一个大问题。确实，它们应该是正交的——例如，通常希望有一个带有日志记录的“调试”构建，但在启用优化的情况下仍然可以快速运行。同样，如果在优化的构建中没有可用的调试符号，可能很难追踪与优化器相关的错误。

                   +--------------------------------+
                   |           Optimizations        |
                   +-----------------+--------------+
                   |        On       |     Off      |
 +----------+------+-----------------+--------------+
 |          |  On  | Debug optimized |  Best debug  |
 |  Debug   |      |    code         |  experience  |
 | Logging/ +------+-----------------+--------------+
 | Symbols  |  Off |   Release build | Probably not |
 |          |      |  for customers  |    useful    |
 +----------+------+-----------------+--------------+
于 2013-08-01T17:08:53.873 回答