前序文章请看:
从裸机启动开始运行一个C++程序(十三)
从裸机启动开始运行一个C++程序(十二)
从裸机启动开始运行一个C++程序(十一)
从裸机启动开始运行一个C++程序(十)
从裸机启动开始运行一个C++程序(九)
从裸机启动开始运行一个C++程序(八)
从裸机启动开始运行一个C++程序(七)
从裸机启动开始运行一个C++程序(六)
从裸机启动开始运行一个C++程序(五)
从裸机启动开始运行一个C++程序(四)
从裸机启动开始运行一个C++程序(三)
从裸机启动开始运行一个C++程序(二)
从裸机启动开始运行一个C++程序(一)
加载64位指令
前一节我们已经成功进入了IA-32e模式,但是,却意料之外地体验了一把在IA-32e模式上运行IA-32指令的兼容模式。
前面我们也看到了IA-32e架构下的硬件扩展方式,比如说寄存器都是在原本基础上扩展的,所以,他可以通过只用低32位寄存器的方式,运行IA-32的指令,以此实现高度兼容。
因此,这里的秘密就是在,段配置的一个保留位上,咱们前面讨论过,段描述符的第54和55位是保留位,因为在IA-32模式下不会去解析这两位。但是IA-32e模式下就利用了其中的第55位,用来表示该段是32位模式还是64位模式,当它为1时,CPU将会用64位指令来解析。
但是,前面分好的代码段我们不能动,毕竟内核这里还有一段32位的代码要执行。所以,我们就再分一个64位指令的段。不过64位的段有一个要求,就是「强制平坦」,也就是说,Base
配置是无效的,强制按照0x0
作为首地址。原因也很简单,因为IA-32e模式强制要求分页,所以他希望操作系统用这种更先进的方式来管理内存,因而分段这里就要求强制平坦。
注意,我们说的强制平坦是仅当第55位置1的情况才会强制平坦,如果这一位是0,那么向下兼容IA-32模式的话,段基址是有效的。
64位段配置如下:
; 5号段-64位代码段
; 基址0x0000,上限0xfffff
mov [es:0x28], word 0x00ff ; Limit=0x00ff,这是低16位
mov [es:0x2a], word 0x0000 ; Base(无效)低16位
mov [es:0x2c], byte 0x0000 ; Base(无效)16~23位
mov [es:0x2d], byte 1_00_1_101_0b ; P=1, DPL=0, S=1, Type=001b, A=0
mov [es:0x2e], byte 1_0_1_0_0000b ; G=1, D/B=0, L=1(开启64位模式), AVL=0, Limit的高4位是0000
mov [es:0x2f], byte 0x00 ; Base(无效)高8位
这样,当我们把CS
设置成5号段的时候就可以执行64位指令了。为此,咱们在kernel中添加一个64位指令,操作一下R8
寄存器,来验证是否能正常执行:
; 进入IA-32e模式
; 刷新cs以进入64位指令模式
jmp 00101_00_0b:ent64 + 0x8000 ; 注意这里,平坦模式下,要从0x0计算偏移量
[bits 64]
ent64:
mov r8, 0x12345678911
hlt
通过调试指令,可以观察这一句的执行情况:
没问题,我们成功在IA-32e模式下运行了64位指令,并且给64位寄存器赋了值。
到此的项目代码将会放在附件(14-1)中,供读者参考。
改造剩余内核代码
既然我们成功进入了64位模式,那么将剩下的代码,改用64位编译模式,就可以链接到当前的内核中,这样我们就可以执行原本编写的C程序了。
C程序的源码是都不用改变的,我们只需要通过调整参数,让编译期按照64位的方式来编译就好了。不过有两个个地方是需要我们来管的,就是asm_func.nas
,因为这个文件是用汇编写的,所以我们需要改造成64位指令。另一个地方是进入entry
函数之前,有一些段和栈的配置需要改造。接下来我们一个一个来:
asm_func的改造
要改造的点有4处:
- 压栈弹栈时要匹配栈的位宽,因此要改成64位寄存器。
- 在64位模式下,由于段已经强制平坦了,因此不再允许用
es
加偏移来操作内存,只能用默认的ds
,因此我们要把其中使用es
的部分改成ds
。 - 因为64位模式强制平坦,所以,原本的2号段无法使用了,我们得配一个新的数据段与其对齐。对应显存的地址也要改变。
- 在32位模式下,C语言规范传参方式都是通过压栈的,因此我们用
[rsp + 12]
的方法找参数。但是64位模式下,由于通用寄存器数量增加,为了更高效,会优先采用寄存器传参的方式。对于6个寄存器以下的情况,会按照rdi
,rsi
,rdx
,rcx
,r8
,r9
的顺序来传参,当大于6个时才会采用压栈的方式。所以读参方式要改造。
MBR的段配置处加一个6号段:
; 6号段-64位数据段
; 强制平坦模式,基址无效,上限0xffffffff
mov [es:0x30], word 0xffff ; Limit=0xffff,这是低16位
mov [es:0x32], word 0x0000 ; Base无效
mov [es:0x34], byte 0x0000 ; Base无效
mov [es:0x35], byte 1_00_1_001_0b ; P=1, DPL=0, S=1, Type=001b, A=0
mov [es:0x36], byte 1_0_1_0_0000b ; G=1, D/B=0, L=1, AVL=0, Limit的高4位是0000
mov [es:0x37], byte 0x00 ; Base无效
; 下面是gdt信息的配置(暂且放在0x07f00的位置)
mov ax, 0x07f0
mov es, ax
mov [es:0x00], word 55 ; 因为目前配了7个段,长度为56,所以limit为55
mov [es:0x02], dword 0x7e00 ; GDT配置表的首地址
; 把gdt配置进gdtr
lgdt [es:0x00]
asm_func
改造后的代码如下:
[bits 64]
section .text
global SetVMem ; 告诉链接器下面这个标签是外部可用的
SetVMem:
; 现场记录
push rbp
mov rbp, rsp
; 过程中用到的寄存器都要先记录
push rbx
push rcx
push rdx
; 64位模式下不允许通过es偏移,所以只能设置ds
mov bx, ds ; 用bx记录原本的ds,用于后续恢复现场(这里是因为寄存器还够用,如果不够用的话就还是要压栈)
; 把es配成数据
mov dx, 00110_00_0b
mov ds, dx
; 通过参数找到addr和data(64位优先用寄存器传参)
mov rdx, rdi ; addr
mov rcx, rsi ; data
; 通过偏移地址来操作显存(0xa0000是显存基址)
mov [rdx+0xa0000], cl ; 由于data是1字节的,所以其实只有cl是有效数据
; 现场还原
mov ds, bx
pop rdx
pop rcx
pop rbx
mov rsp, rbp
pop rbp
; 回跳
ret
kernel的改造
在kernel.nas
中,进入entry
函数之前,我们要做段寄存器的配置,所以我们把ds
、es
和ss
都配置为平坦模式的数据段,也就是6号段,代码如下:
mov ax, 00110_00_0b ; 选择6号段,数据段
mov ss, ax
; ds要跟ss一致
mov ds, ax
; es也初始化为数据段(防止后续出问题,先初始化)
mov es, ax
; 初始化栈
mov rax, 0x1000
mov rsp, rax ; 设置初始栈顶
mov rbp, rax ; ebp也记录初始栈顶
extern Entry
call Entry
hlt
配置参数改造
接下来就是通过调整参数,把这些.nas
和.c
通过64位方式编译,并链接起来。
C编译参数要用-m64 -march=x86-64
来生成64位的.o
文件,nas
的编译参数要用-f elf64
来生成64位`.o``文件。
链接时也要用-m elf_x86_64
参数,而且要注意一个严重问题,由于现在分段是平坦模式了,所以程序加载的内存地址不再是0
的偏移量,而是0x8000
,所以链接参数要做调整-Ttext=0x8000
。
最后objcopy
时也要制定参数elf64-x86-64
,要注意这个指令的参数是用中划线而不是下划线,跟前两个指令要区分开。
完整的kernel
的makefile
如下:
.PHONY: all
all: kernel_final.bin
kernel.o: kernel.nas
nasm kernel.nas -f elf64 -o kernel.o
entry.o: entry.c ../libc/include/stdio.h
# 需要用-I制定头文件扫描位置
x86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin -I../libc/include entry.c -o entry.o -Wall -Werror -Wextra
../libc/libc.a:
pushd ../libc && $(MAKE) clean && $(MAKE) libc.a && popd
kernel_final.out: kernel.o entry.o ../libc/libc.a
# 需要用-L指定静态链接库位置
# -lc表示链接libc.a
# 注意kernel.o要放在第一个
x86_64-elf-ld -m elf_x86_64 -Ttext=0x8000 kernel.o entry.o -L../libc -lc -o kernel_final.out
kernel_final.bin: kernel_final.out
x86_64-elf-objcopy -I elf64-x86-64 -S -R ".eh_frame" -R ".comment" -O binary kernel_final.out kernel_final.bin
.PHONY: clean
clean:
-rm -f .DS_Store
-rm -f *.bin
-rm -f *.o
-rm -f *.out
同理,调整libc
的配置文件如下:
.PHONY: all
all: libc.a
font.o: font.c
x86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin font.c -o font.o
stdio.o: stdio.c include/stdio.h
x86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin stdio.c -o stdio.o
string.o: string.c include/string.h
x86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin string.c -o string.o
asm_func.o: asm_func.nas
nasm asm_func.nas -f elf64 -o asm_func.o
libc.a: asm_func.o stdio.o string.o font.o
# $^表示所有依赖文件
# ar是制作静态链接库的工具
x86_64-elf-ar -crv --target=elf64-x86-64 libc.a $^
.PHONY: clean
clean:
-rm -f *.o libc.a
看一眼64位改造后的成果
都改造完毕后就可以尝试运行了,这是我们第一次在64位模式下运行完整的程序:
完美!该部分的项目源码将会放在附件(14-2)中,供读者参考。
加一个C++程序
终于,我们到了邀请最终大咖登场的环节了。既然64位C语言程序已经可以正常运行,那么同理,我们把C++代码编译成elf64
格式的文件,链接到Kernel中,照理说就大功告成了。
因此,我们先在工程中建立一个main.cpp
,然后在makefile
中编写对应的构建命令:
main.o: main.cpp
x86_64-elf-g++ -c -std=c++17 -m64 -march=x86-64 -fno-builtin -I../libc/include main.cpp -o main.o -Wall -Werror -Wextra
# 注意链接的时候要加上main.o
kernel_final.out: kernel.o entry.o main.o ../libc/libc.a
x86_64-elf-ld -m elf_x86_64 -Ttext=0x8000 kernel.o entry.o main.o -L../libc -lc -o kernel_final.out
这里用来编译C++代码的指令是x86_64-elf-g++
,这里我们指定C++17标准,其余参与跟C语言的entry.c
相同,不再赘述。
然后我们在main.cpp
中实现main
函数,但是有一点要注意,因为程序实际的入口是Entry
,所以需要在Entry
中调用main
函数。不过既然已经有了这一步调用,我们索性就把函数返回值打印出来,代码如下:
void Entry() {
// 背景设置为白色
SetBackground(0x0f);
extern int main();
int ret = main();
printf("main() returned by: %d", ret);
}
接下来我们来实现main
函数。有一点需要注意的是,由于C++是支持函数重载的,所以参与链接的函数符号并不仅仅是函数名,还包含了参数信息。这种构建方式是C语言不支持的,因此,我们想在entry.c
中调用main.cpp
中的main
函数,还需要对这个函数进行额外的声明,告诉编译器采用原始C的方式做链接符号。
声明的方法是使用extern "C"
关键字。需要知晓的是,用C方式编译的函数不再支持重载,但可以和C语言源码链接上:
extern "C"
int main() {
return 0;
}
好了,运行一下看看效果吧:
大功告成,我们实现了「从裸机启动开始运行一个C++程序」的任务,撒花!!~~
……
真的大功告成了吗?哈哈!当然没那么简单,C++不像C那么纯粹,它存在很多隐含的动作,只是因为目前main
函数过于简单,我们还没有踩任何坑而已。
因此,我们不能过于激动,还是要沉下心来继续进行一段修炼。 不过不用操之过急,可以先享受片刻胜利的喜悦,下一章我们再来看看上了C++之后会碰到哪些问题。
到此的项目源码会放入附件(14-3)中,供读者参考。
小结
这一篇我们介绍了如何在IA-32e模式中运行64位指令,还介绍了如何把C语言编译成64位指令,以及配套的asm_func
如何改造。最后成功把C++程序加入了项目中。
本篇的所有项目源码将会放在附件(demo_code_14)中,供读者参考。