Gdb：gcc -O0 assmbly exmple

編譯時沒有指定優化：gcc test.c -o test（它似乎選擇了-O0）。

gcc -O2或-O3輸出比O0更清潔（至少在我看來）彙編代碼。

-O0是什麼原因，它對我們有什麼幫助，我看不出它比-O1或-O2簡單。

... 
int sum(int x, int y) 
{ 
    int sum = x + y; 
    return sum; 
} 
... 

0x00000000004004ed <+0>:  push %rbp 
0x00000000004004ee <+1>:  mov %rsp,%rbp 
0x00000000004004f1 <+4>:  mov %edi,-0x14(%rbp) 
0x00000000004004f4 <+7>:  mov %esi,-0x18(%rbp) 
0x00000000004004f7 <+10>: mov -0x18(%rbp),%eax 
0x00000000004004fa <+13>: mov -0x14(%rbp),%edx 
0x00000000004004fd <+16>: add %edx,%eax 
0x00000000004004ff <+18>:  mov %eax,-0x4(%rbp) 
0x0000000000400502 <+21>: mov -0x4(%rbp),%eax 
0x0000000000400505 <+24>: pop %rbp 
0x0000000000400506 <+25>: retq

來源

2017-03-28 dud3

它更直接映射到源代碼。 – Jester

一些安全關鍵的應用程序，無論是汽車還是飛機或醫療等，都可能規定他們不希望進行優化，因爲驗證編譯器輸出與源輸入是否正確匹配太困難。它是一個移動目標，在沒有優化的情況下，理想情況下工具鏈可以被驗證，或者相對更容易，或者二進制文件中有更多的舒適級別。 –

同樣沒有優化，您可以通過優化的死代碼被刪除的代碼進行調試，單步執行等，某些代碼可能會重新排列，高級和輸出之間不存在一對一的關係，因此您無法一步步，你不一定要看內存或變量等。 –

隨着優化關斷時，存在一個1：源代碼和機器代碼之間1表示，允許更容易的調試。在開啓優化的情況下，編譯器可以做一些奇怪的事情，比如重新編排代碼或刪除使代碼更難調試的變量。

編譯-O0通常也更快，因爲優化器通常是每個現代編譯器中最慢的組件。

來源

2017-03-28 16:40:01 fuz

Gdb：gcc -O0 assmbly exmple

回答

相關問題