这得从vmliux.bin的产生过程说起。

　　从内核的生成过程来看内核的链接主要有三步：

　　步是把内核的源代码编译成.o文件，然后链接，这一步，链接的是arch/i386/kernel/head.S，生成的是vmlinux。注意的是这里的所有变量地址都是32位页寻址方式的保护模式下的虚拟地址。通常在3G以上。

　　第二步，将vmlinux objcopy 成arch/i386/boot/compressed/vmlinux.bin，之后加以压缩，作为数据编译成piggy.o。这时候，在编译器看来，piggy.o里根本不存在什么artup_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()

　　这是一段自解压程序，过程和内核生成的过程正好相反。这时，处在32位段寻址方式的保护模式下，寻址范围从1M扩大到4G。只是没有页表。

　　我们对具体的解压过程不感兴趣。

　　内核解压完毕。位于0x100000即1M处

　　，执行一条跳转指令，执行0x100000处的代码，即startup_32()，这回是arch/i386/kernel/head.S中的startup_32()代码

　　ljmp $(__BOOT_CS), $__PHYSAL_START