我目前正在研究低级别的操作系统组织。为了实现我想要了解Linux内核是如何加载的。
我无法理解的是从16位(实模式)到32位(保护模式)的转换。它发生在this file。
protected_mode_jump
函数对稍后执行的32位代码执行各种辅助计算,然后在PE
reguster中启用CR0
位
movl %cr0, %edx
orb $X86_CR0_PE, %dl # Protected mode
movl %edx, %cr0
然后执行长跳转到32位代码:
# Transition to 32-bit mode
.byte 0x66, 0xea # ljmpl opcode
2: .long in_pm32 # offset
.word __BOOT_CS # segment
据我所知in_pm32
是32位函数的地址,它在protected_mode_jump
下方声明:
.code32
.section ".text32","ax"
GLOBAL(in_pm32)
# some code
# ...
# some code
ENDPROC(in_pm32)
__BOOT_CS
扇区基数为0(事先设置GDT here),这意味着偏移量基本上应该是in_pm32
函数的绝对地址。
这就是问题所在。在机器代码生成期间,汇编器/链接器不应该知道in_pm32
函数的绝对地址,因为它不知道在实模式下它将在内存中加载的位置(各种引导加载程序可以占用不同的空间,并且在引导加载程序之后加载实模式内核。
此外,链接器脚本(同一文件夹中的setup.ld
)将代码的原点设置为0,因此似乎in_pm32
地址将是实模式内核开头的偏移量。它应该可以正常使用16位代码,因为CS
寄存器设置正确,但是当发生长跳转时,CPU已经处于保护模式,因此相对偏移量不起作用。
所以我的问题:
如果偏移量(.byte 0x66, 0xea
)是相对的,保护模式(.long in_pm32
)中的跳远为什么设置正确的代码位置?
似乎我错过了一些非常重要的东西。
答案 0 :(得分:5)
看来你的问题实际上是关于存储在下一行的偏移量如何可能有效,因为它是相对于段的开始,不一定是内存的开始:
2: .long in_pm32 # offset
in_pm32
确实相对于linker script使用的偏移量。特别是链接描述文件具有:
. = 0;
.bstext : { *(.bstext) }
.bsdata : { *(.bsdata) }
. = 495;
.header : { *(.header) }
.entrytext : { *(.entrytext) }
.inittext : { *(.inittext) }
.initdata : { *(.initdata) }
__end_init = .;
.text : { *(.text) }
.text32 : { *(.text32) }
虚拟内存地址设置为零(以及随后的495),因此可以认为.text32
部分中的任何内容都必须在低内存中修复。如果不是protected_mode_jump
中的这些说明,那么这是正确的观察结果:
xorl %ebx, %ebx
movw %cs, %bx
shll $4, %ebx
addl %ebx, 2f
[snip]
# Transition to 32-bit mode
.byte 0x66, 0xea # ljmpl opcode
2: .long in_pm32 # offset
.word __BOOT_CS # segment
最后有一个手动编码的 FAR JMP ,用于将 CS 选择器设置为32位代码描述符,以完成向32位的转换保护模式。但要注意的关键是这些方面:
xorl %ebx, %ebx
movw %cs, %bx
shll $4, %ebx
addl %ebx, 2f
这将取 CS 中的值并将其向左移4位(乘以16),然后将其添加到存储在标签2f
中的值。这是你采用real mode segment:offset对并将其转换为线性地址(在这种情况下与物理地址相同)的方式。标签2f
实际上是此行中的偏移in_pm32
:
2: .long in_pm32 # offset
当这些指令完成后, FAR JMP 中的长字值in_pm32
将通过添加当前实模式代码段的线性地址来调整(在运行时)值in_pm32
。此.long
(DWORD)值将替换为(CS <&lt;&lt;&lt;#4)+ in_pm32。
此代码旨在可重定位到任何实模式段。最终的线性地址是在 FAR JMP 之前的运行时计算的。这实际上是自修改代码。