OSDev.org

How do I create/load a GDT when I am in PMode as opposed to Real Mode? What are the differences? In my gdt.s, do I specify bits 16 or bits 32? Do I switch back into real mode, load the GDT, and switch into Pmode? Or what?

The reason I am asking is because I am using the GRUB2 bootloader, which (I understand) puts you into Pmode, and I have not yet set up any GDT.

It's exactly the same.

One difference, in RMode, LGDT takes 24 bit linear address; in PMode, LGDT takes 32 bit linear address. The same is true for SGDT, LIDT/SIDT.

trinopoty wrote:One difference, in RMode, LGDT takes 24 bit linear address; in PMode, LGDT takes 32 bit linear address. The same is true for SGDT, LIDT/SIDT.

Utter nonsense. Even if you never heard of operand sizes and prefixes there's no way you're going to explain how you established the above.

trinopoty wrote:One difference, in RMode, LGDT takes 24 bit linear address; in PMode, LGDT takes 32 bit linear address. The same is true for SGDT, LIDT/SIDT.

What pointer are you talking about?

The GDTP itself, which is size:linear base, thus 48-bit in realmode/pmode, and 80-bit in long mode.

Or the pointer to the GDTP, which is the argument of lgdt. This pointer is an ordinary offset within the current segment (not a linear adress), thus the size depends on the current segment size (unless overridden with a prefix).

Either way, you are wrong.

Combuster wrote:

trinopoty wrote:One difference, in RMode, LGDT takes 24 bit linear address; in PMode, LGDT takes 32 bit linear address. The same is true for SGDT, LIDT/SIDT.

Utter nonsense. Even if you never heard of operand sizes and prefixes there's no way you're going to explain how you established the above.

I got the result on my own Core 2 Duo machine.
Even using prefix did not help in the case.

trinopoty wrote:I got the result on my own Core 2 Duo machine.

Proof wanted. At least it gives us an opportunity to point out the bugs that must be present in your code (or brain cells)

Hi,

Combuster wrote:

trinopoty wrote:I got the result on my own Core 2 Duo machine.

Proof wanted. At least it gives us an opportunity to point out the bugs that must be present in your code (or brain cells)

He's mostly right (although the difference is in operand size, not real mode vs. protected mode). Basically, for LGDT if the operand size is 16-bit the CPU loads a 32-bit base address then masks it so that the upper 8 bits are zero/unused and you end up with a 24-bit GDT base address being loaded, and if the operand size is 32-bit then no masking occurs and a full 32-bit GDT base address is loaded.

Of course in real mode or 16-bit protected mode code you can use an operand size override prefix to get a full 32-bit GDT base address (unless the CPU is an 80286), and in 32-bit protected mode code you can use an operand size override to limit the base address to 24-bit.

Also note that the reason for this "unusual" behaviour is backward compatibility - the 80286 only supported 24-bit addressing, so to make 32-bit CPUs work the same...


Cheers,

Brendan

An operand size difference is possible as I tend to not specify any operand size explicitly.
To be honest, I just write the code and let the assembler/compiler generate whatever they want, given that it works as I expect.
When I first saw the problem, I did not care as I knew the kernel will change the GDT later anyway.