从裸机启动开始运行一个C++程序（十四）

前序文章请看：
从裸机启动开始运行一个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, 0x12345678911hlt

通过调试指令，可以观察这一句的执行情况：
执行效果

没问题，我们成功在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 rbpmov rbp, rsp; 过程中用到的寄存器都要先记录push rbxpush rcxpush rdx; 64位模式下不允许通过es偏移，所以只能设置dsmov bx, ds ; 用bx记录原本的ds，用于后续恢复现场（这里是因为寄存器还够用，如果不够用的话就还是要压栈）; 把es配成数据mov dx, 00110_00_0bmov ds, dx; 通过参数找到addr和data（64位优先用寄存器传参）mov rdx, rdi ; addrmov rcx, rsi ; data; 通过偏移地址来操作显存（0xa0000是显存基址）mov [rdx+0xa0000], cl  ; 由于data是1字节的，所以其实只有cl是有效数据; 现场还原mov ds, bxpop rdxpop rcxpop rbxmov rsp, rbppop 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 Entryhlt

配置参数改造

接下来就是通过调整参数，把这些.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.binkernel.o: kernel.nasnasm kernel.nas -f elf64 -o kernel.oentry.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 && popdkernel_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.outkernel_final.bin: kernel_final.outx86_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.afont.o: font.cx86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin font.c -o font.ostdio.o: stdio.c include/stdio.hx86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin stdio.c -o stdio.ostring.o: string.c include/string.hx86_64-elf-gcc -c -m64 -march=x86-64 -fno-builtin string.c -o string.oasm_func.o: asm_func.nasnasm asm_func.nas -f elf64 -o asm_func.olibc.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.cppx86_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语言源码链接上：