OSDev.org

I'm having paging issues and I'm having a hard time figuring out how to debug them.

GDB kind of works, but it's buggy and changes lines out of nowhere.

QEMU will tell me where the exception happened (loading cr3), but that doesn't really help either.

I want to know how I can examine the page tables at runtime.

From my understanding, page tables are huge, and I don't know how I would get that information.

Does anyone have any insights?

QEMU has 'info mem' and 'info tlb' monitor commands for that purpose. And, ohhh boi… how many times it saved me hours of debugging. Also, when debugging with QEMU's GDB stub it's best NOT to use kvm or any other hardware virtualization. Just plain old software emulation. Otherwise, you're going to encounter a lot of weirdness.

rizxt wrote: GDB kind of works, but it's buggy and changes lines out of nowhere.

I find that statement very surprising; I've never had any appreciable problems with gdb. Natuarally, you have to turn off all optimization if you want the generated code to correspond accurately with the source.

QEMU will tell me where the exception happened (loading cr3), but that doesn't really help either.

Well it should. It's telling you that your page table is invalid or that you haven't mapped some memory that you use. All you have to do is to inspect the page table to see where the problem is.

I want to know how I can examine the page tables at runtime.

Page tables are just data in memory. You can inspect it in the same way that you would inspect any other memory. If you don't like gdb then use the qemu monitor.

From my understanding, page tables are huge, and I don't know how I would get that information.

No; page tables are relatively small arrays.

OK, so now I see that PML4 is stored at 0x1000, which is not right. This means I didn't reserve the pages from 0x1000-0x10000, and when I requested a page for PML4, it gave me 0x1000.

Paging code is probably the hardest beginner part of OSDev. I would recommend learning 32 bit paging first (it is much simpler, just two levels), and then really understand it. The you can do 4 level, and maybe even 5 levels of paging. Note that memory management is very complex, meaning that you really need to understand concepts like CoW, demand paging, page swapping and other things when making a memory manager. I agree with @pvc, use info tlb, or try out Bochs emulator, they will make debugging paging code much simpler. I once had a bug in my paging code dealing with canoncial addresses, and without Bochs and @iansjack, I would probably still be confused

My issue is that my PML4 address was going to 0x1000, which is no-go-zone memory. However, I reserved the pages from 0x1000-0x10000, and my memory::paging::allocation::request_page() function would return nullptr. which leads me to believe that my bitmap isn't set up properly.

Closer to the root cause, my memory size function is returning a size of 4 kilobytes (1 page). Looks like an issue with parameters.

i'm actually sobbing right now because the root cause was me passing the number of memory map entries to my memory size function instead of the map size