這得從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