4

私が見たほとんどのビルド環境には、少なくとも 2 つの戦略があります: デバッグ ビルドと最終/最適化/リリース ビルドです。-ggcc では、これは通常vsのあるバージョンを意味し-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 に答える