在使用gdb或者其他工具除錯預設優化選項的核心時，核心的反彙編**與原來的c語言**對應很亂。如果切換到c語言模式，使用單步除錯時會看到執行順序在c語言源**裡面跳來跳去，甚是紊亂。
這一切都是gcc對**進行了優化造成的，優化後的**執行順序與源**的順序就有出入了。gcc優化**，提高執行效率與**緊湊度，但對於除錯學習核心就不友好了。
通過下面的方法去掉核心編譯時的優化。
1，優化級別從-o2改為-o1
修改核心源**根目錄下的makefile
all: vmlinux
ifdef config_cc_optimize_for_size
kbuild_cflags += -os
else
kbuild_cflags += -o1
endif
config_cc_optimize_for_size預設是不定義的，所以修改紅色部分為-o1，優化級別為1級，只做基本的優化。
2，不要將只有乙個地方呼叫的函式自動變為inline函式
變為inline函式之後，對於除錯**極為不便。原來在裡面定義的區域性變數都沒有了，要檢視一些區域性變數的值時需要從暫存器裡面去推導，並且需要手動的做強制型別轉換才能看到資料結構的值。
禁止inline後會是一次真正的函式呼叫，對於通過除錯理解**功能作用很大。
# we trigger additional mismatches with less inlining
ifdef config_debug_section_mismatch
kbuild_cflags += $(call cc-option, -fno-inline-functions-called-once)
endif
config_debug_section_mismatch這個巨集本來是檢測**/資料段型別屬性不匹配的，定義後同時有個功能是禁止將只有乙個地方呼叫的函式變為inline函式。
附：編譯qemu的arm vexpress平台的核心命令：
linux-3.4.70$ make o=/home/dazhi/vexpress/build/kernel arch=arm cross_compile=arm-linux- vexpress_defconfig menuconfig
linux-3.4.70$ make o=/home/dazhi/vexpress/build/kernel arch=arm cross_compile=arm-linux-
採用android工具鏈編譯：
make -c sourcecode/linux-3.4.70/ o=/home/dazhi/linuxbuild/ arch=arm cross_compile=/home/dazhi/androidl/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi- versatile_defconfig menuconfig
make -c sourcecode/linux-3.4.70/ o=/home/dazhi/linuxbuild/ arch=arm cross_compile=/home/dazhi/androidl/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi-
gcc 編譯優化選項
o0 這個等級 字母 o 後面跟個零 關閉所有優化選項，也是cflags或cxxflags中沒有設定 o等級時的預設等級。這樣就不會優化 這通常不是我們想要的。o1 這是最基本的優化等級。編譯器會在不花費太多編譯時間的同時試圖生成更快更小的 這些優化是非常基礎的，但一般這些任務肯定能順利完成。o2 ...
檢視Linux系統核心編譯選項
有時候我們需要檢視linux系統的核心是否在編譯的時候的編譯選項，從而確定某個模組是否已經加入到核心以及引數設定等等。方法有兩種 zcat proc config.gz cat boot config uname r 第一種方法要求在核心編譯時增減相應的選項才會生成，很多系統找不到 proc con...
關於編譯優化選項o3的問題
今天我在優化 的時候。出現了問題。如下 periph.c 讀暫存器，引數 位址 返回內容 unsigned int readcmd unsigned char addr main.c define readhdat0 readcmd spi hdat0 hdat0 readhdat0 讀 檔案幀頭資...