OSDev.org

Hello!
I decided to move my kernel to 64bits. In my bootstrap code, which is the entry point GRUB jumps to, I set up paging and all that, and right after enabling paging I instantly get a crash. The cause of the crash is a triple fault because I haven't set any interrupt handlers and all that. The address in cr2 at the time of the exception is 0x00000000000000af. I cannot figure out why that happens, but it's probably something easy that I didn't notice. Source code of the bootstrap code is https://github.com/0xqookie/KukkiOS/blo ... oot/boot.S

Single-step the code in a debugger. And set up exception handlers.

Probably your very first page is badly set up and it faults when you try to access a byte in 0xAF.

Hi,

qookie wrote:I decided to move my kernel to 64bits. In my bootstrap code, which is the entry point GRUB jumps to, I set up paging and all that, and right after enabling paging I instantly get a crash. The cause of the crash is a triple fault because I haven't set any interrupt handlers and all that. The address in cr2 at the time of the exception is 0x00000000000000af. I cannot figure out why that happens, but it's probably something easy that I didn't notice. Source code of the bootstrap code is https://github.com/0xqookie/KukkiOS/blo ... oot/boot.S

There's problems with "address fix-ups" in multiple places because you've forgotten to adjust for the address the code is actually loaded.

For example, if the linker thinks that "init_pml4:" is at 0xffffffff800012000 but it's actually at the (physical) address 0x0x00112000 (because GRUB loaded it at 1 MiB and not at 0), then you do "movl $(init_pml4 - KERNEL_VMA), %eax" and load the value 0x0x00012000 into EAX (and don't load the value 0x0x00112000 into EAX).

You'd probably want to add "#define LOAD_PHYSICAL_ADDRESS 0x00100000" somewhere; then change most of your address fix-ups to be more like "init_pml4 - KERNEL_VMA + LOAD_PHYSICAL_ADDRESS".


Cheers,

Brendan

@Brendan

The 0xffffffff80000000 address is mapped to the 0x0000000000000000, and the kernel is loaded at 2 MiB, so everything should be at the correct positions after just subtracting the KERNEL_VMA. I am suspicious of the 0xffffffff... part, it may be causing problems.

My god, I just realized my linker script defines KERNEL_VMA as 0xFFFFFFFF80000000 + KERNEL_LMA instead of just 0xFFFFFFFF80000000