这得从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