既-g3和-O3

編譯大多數構建環境我已經看到至少有兩種策略：調試版本VS最終/優化/發佈版本。與海灣合作委員會，這通常意味着的-g VS -O一些版本。現在我看到在優化的建立是建立與-O3而調試版本與-g3和-O3建的情況。 man gcc確實表明這是可能的，但是這似乎違反直覺我要真正的調試。既-g3和-O3

查看http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html讓我想起了-Og，它允許不干擾調試的優化。這對我來說很有意義，但是是什麼令人信服的理由，還有與-O3 -g3調試，除非你基本上是試圖調試GCC自身的優化能力？

來源

2013-08-01 patrickvacek

..或者如果您試圖調試優化後的代碼（這可能與未優化的代碼有不同的錯誤）。究竟是什麼問題？ –

問題是，爲什麼我期待在環境編譯調試版本與'-O3 -g3'。我試圖弄清楚，只有'-g3'，你不能學習什麼信息。我隱約知道你也提供了答案，但我正在尋找例子或進一步澄清。 – patrickvacek

有時候人們寫的不好的代碼 - 也許這會導致不確定的行爲，例如代碼。現在讓我們假設未定義的行爲似乎在低優化或不優化的情況下「正確地」工作，但是它在-O3處導致災難性的崩潰。你將要在-O3調試這個問題，對吧？因此，除了增加一個-g標誌並前往城鎮外，您別無選擇，即使調試體驗可能會因優化而受到一定程度的損害。

有一般一個大問題，構建系統的混爲一談「調試/發佈」軸與「優化/未優化」軸。說真的，他們應該是正交的 - 它往往需要有「調試」伐木建，例如，但仍然有它啓用了優化，運行速度快。同樣，如果您的優化版本中沒有可用的調試符號，追蹤優化器相關的錯誤可能非常困難。

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

來源

2013-08-01 17:08:53

回答

相關問題