OSDev.org

core2extreme wrote: ↑Fri Mar 07, 2025 5:57 pmBecause the GDT loads fine and the PE bit is set fine.

The CPU doesn't check the GDT when you load GDTR or set the PE bit. Neither of those things are proof that your GDT is correct.

The CPU does check the GDT when you do a far jump.

Octocontrabass wrote: ↑Fri Mar 07, 2025 6:04 pm

core2extreme wrote: ↑Fri Mar 07, 2025 5:57 pmBecause the GDT loads fine and the PE bit is set fine.

The CPU doesn't check the GDT when you load GDTR or set the PE bit. Neither of those things are proof that your GDT is correct.

The CPU does check the GDT when you do a far jump.

Oh, wait, really? Guess I better get to reading the wiki and writing my own GDT... thanks for the help!

You can use LGDT to load complete rubbish from the GDT record and it won't fail. You can have a valid GDT record and bogus entries in the GDT and LGDT won't fail. You can enable the protected mode bit and it won't immediately fail. The failures will occur when the processor attempt to read a selector into a segment register (ES/DS/CS/GS/FS/SS). CS in your code is set with the FAR JMP. So your code could have bad GDT table or GDT record and have set the PE bit and only start failing at the FAR JMP instruction because CS is being reloaded and the CPU needs to get the selector info from the GDT.

Update: I started writing this up before Octo posted his last comment.

you can use bochsdbg.exe to trace cpu execute step by step, that's convenient than qemu.