OSDev.org

iocoder
You mean to say in every task's page directory GDT's linear address is mapped. So it's like GDT's page is shared by all the tasks in system.

if your GDT is located in kernel space (like it should anyway) typically, the kernel space is always the same in every process anyway (because every process needs access to other things as well, such as the physical/virtual memory managers, exception handlers, and kernel services) so as long as the GDT is mapped into kernel space, then it will automatically be mapped identically in every process without you having to worry about it

Dinesh wrote:iocoder
You mean to say in every task's page directory GDT's linear address is mapped. So it's like GDT's page is shared by all the tasks in system.

EXACTLY. One GDT table for the whole system (stored in physical memory) appears at certain linear base address x for every page directory. GDTR contains that x and the limit.

iocoder JAAman iansjack
Thanks guys

Brendan wrote: The LGDT and SGDT instructions use a linear address. This is not necessarily the same as a virtual address (if you use segmentation), and not necessarily the same as a physical address (if you use paging).

You should probably be more clear here.

LGDT, SGDT, LIDT and SIDT use the logical address (segment selector:offset) of the instruction operand to access it. Logical is then translated into linear/virtual, which is then either the final physical address or subject to further virtual-to-physical translation using the page tables.

The operand (resides in memory) contains the table address and its limit (the limit ultimately gives the table size).
The table address is linear/virtual, which, again, may be subject to further virtual-to-physical translation.

iocoder wrote:In this case you may simply let GDT appear in the address space of every process, although some may argue that this is a bad design.

And who are those people? Is there anyone else who believe that having the GDTR pointing to invalid memory is a good design?