這得從vmliux.bin的產生過程說起。
從核心的生成過程來看核心的鏈結主要有三步：
第一步是把核心的源**編譯成.o檔案，然後鏈結，這一步，鏈結的是arch/i386/kernel/head.s，生成的是vmlinux。注意的是這裡的所有變數位址都是32位頁定址方式的保護模式下的虛擬位址。
通常在3g以上。
第二步，將vmlinux objcopy 成arch/i386/boot/compressed/vmlinux.bin，之後加以壓縮，最後作為資料編譯成piggy.o。這時候，在編譯器看來，piggy.o裡根本不存在什麼startup_32。
第三步，把head.o,misc.o和piggy.o鏈結生成arch/i386/boot/compressed/vmlinux，這一步，鏈結的是arch/i386/boot/compressed/head.s。這時arch/i386/kernel/head.s中的startup_32被壓縮，作為一段普通的資料，而被編譯器忽視了。注意這裡的位址都是32位段定址方式的保護模式下的線性位址。
自然，在這過程中，不可能會出現startup_32重定義的問題。
你可能會說：太bt了，平時誰會採用這種方式編譯程式？
是啊，然而在核心還沒啟動的情況下，要高效地實現自解壓，還有更好的方式麼？
所以前面的問題就迎刃而解。
setup執行完畢，跳轉到vmlinux.bin中的startup_32()是arch/i386/boot/compressed/head.s中的startup_32()
這是一段自解壓程式，過程和核心生成的過程正好相反。
這時，cpu處在32位段定址方式的保護模式下，定址範圍從1m擴大到4g。只是沒有頁表。
我們對具體的解壓過程不感興趣。
核心解壓完畢。位於0x100000即1m處
最後，執行一條跳轉指令，執行0x100000處的**，即startup_32()，這回是arch/i386/kernel/head.s中的startup_32()**
ljmp $(__boot_cs), $__physical_start
週六早上讀核感悟
今天週六，因為老婆還要早起備課，我也就跟著早早起來了，九點半就起床了，閒來無事就看了一會 懶得寫 看 總可以了吧，主要看了兩塊，都是關於記憶體的，乙個是核心高階臨時對映，乙個是夥伴系統的per cpu pages中的冷熱頁面佇列，乙個乙個說。關於高階對映的原理我就不多說了，核心 很清晰，基本就是在虛...
週六早上讀核感悟
今天週六，因為老婆還要早起備課，我也就跟著早早起來了，九點半就起床了，閒來無事就看了一會 懶得寫 看 總可以了吧，主要看了兩塊，都是關於記憶體的，乙個是核心高階臨時對映，乙個是夥伴系統的per cpu pages中的冷熱頁面佇列，乙個乙個說。關於高階對映的原理我就不多說了，核心 很清晰，基本就是在虛...
讀核日記 《Linux核心完全注釋》
linux核心完全注釋 v1.9.5版說明 linux 核心 6.程序間通訊機制 linux 核心 4.記憶體管理 linux 核心 5.linux程序 linux 核心 3.軟體基礎 linux 核心 2.硬體基礎 linux 核心 1.前言 讀核日記 八 linux的記憶體管理機制 2 讀核日記...