01
編譯選項和核心編譯
首先我們都知道,Linux核心如果用O0編譯,是無法編譯過的,Linux的核心編譯,要麼是O2,要麼是Os,這點從Linux的Makefile裡面可以看出:
當選擇了
CONFIG_CC_OPTIMIZE_FOR_SIZE
它會是Os,否則就是O2。
其實O2和Os,都是一些最佳化選項的集合:
gcc -c -Q -O2 –help=optimizers > /tmp/O2-opts
gcc -c -Q -Os –help=optimizers > /tmp/Os-opts
前者傾向於基於速度的最佳化,後者傾向於基於size更小的最佳化。對比二者的開關選項:
meld /tmp/O2-opts /tmp/Os-opts
發現差異小的可憐:
O2和Os都使能了inline small函式和called once的函式,但是O2裡面-finline-functions是關閉的,而Os裡面是開的。O2裡面optimize-strlen是開的,Os裡面這個選項是關閉的。相關選項的含義可以透過”man gcc”看出(有問題,找男人),譬如man gcc後檢索inline-functions:
從O0到O1,O2,O3,是一個開啟的最佳化選項逐步加大的過程:
kernel用O0編譯不過,是因為kernel本身也沒有想用O0能夠編譯過,它的設計裡麵包含了編譯會最佳化的假想。下麵我們用一個簡單的例子來說明。
02
一個簡單的例子
下麵的程式碼:
O0編譯會報如下錯,說f()函式沒有定義:
$ gcc -O0 cc.c
cc.c:1:13: warning: ‘f’ used but never defined [enabled by default]
void f(void);
^
/tmp/ccTwwtHG.o: In function `main’:
cc.c:(.text+0x19): undefined reference to `f’
collect2: error: ld returned 1 exit status
但是用O2編譯,則沒有問題:
$ gcc -O2 cc.c
原因在於,O2編譯,它意識到a==1,所以if(a>2),它不會成立,所以f()沒有定義也沒有關係。
把程式碼稍微改一下後:
O2這個時候也不行了:
$ gcc -O2 cc.c
/tmp/ccXiyBHn.o: In function `main’:
cc.c:(.text.startup+0x7): undefined reference to `f’
collect2: error: ld returned 1 exit status
所以,透過這個例子,大家可以看出來為什麼同樣的程式碼,用O2就可以過,用O0就過不了。核心裡面有許多類似設想編譯器會進行最佳化的程式碼。
3.我們不想inline了
由於編譯的最佳化,有些函式(比如小函式和全工程裡面只被一個人呼叫的函式)雖然沒有顯示地寫成inline,但是編譯器最佳化為inline了,這給除錯造成了一些麻煩,因為找不到這個函式對應的symbol了。
這個時候,我們可以顯示地寫明某些函式我們不想inline:
否則,上面2個函式,即便你程式碼裡面沒有寫inline,由於O2和Os使能了相關的inline選項,也可能被編譯器自動inline掉,如果我們想拒絕inline,可以透過noline來標識。
4.我不想被最佳化
在全域性已經使能O1, O2, O3, Os的情況下,某個單獨的函式我們不想做任何的最佳化,可以用__attribute__((optimize(“O0”)))來修飾這個函式,比如我們把上述用O2可以編譯過的程式碼進行如下修改:
重新用O2編譯:
$ gcc -O2 cc.c
/tmp/cc8M338p.o: In function `main’:
cc.c:(.text+0x19): undefined reference to `f’
collect2: error: ld returned 1 exit status
5. 總結的話
下麵給幾條實踐指南:
-
儘量不要嘗試用O0去編譯核心,這不符合真實的工程實踐,也不太被主流Linux社群所支援;核心依賴O2/Os去做較多的最佳化;
-
追求你的程式碼在O2的情況下,仍然是正確的,程式碼要經得起編譯最佳化;比如O0工作正常,而O2不正常,應該盡可能從自身找原因,分析彙編;
-
如果在全域性最佳化的情況下,想針對某個區域性避免最佳化,可以嘗試用noinline,__attribute__((optimize(“O0”)))等進行外科手術式地調整。