OSDev.org

Ok, I read a text about descriptors and I found out this:

Before you can access a segment (i.e. code, data, stack segment), the PC looks into the GDT. The GDT knows where these segments are and defines the access privileges. Right so far?
Okay, LDT is the same as GDT, with the difference, that it defines the memory address and access privileges for *task* segments.
IDT defines the memory address of the Interrupt Code which is called, when a certain interrupt arrives...

Okay, so far it is clear. But what is a segment selector? What for do I use it and how?
And the second question: What are gates? What for do I need them?

I'd be really happy if you could answer me these questions, because then, I understand the architecture of a x86 PC!

LDT acts like a GDT, but it *cannot* hold task segments (TSS). However, each task can be given a specific LDT, while the GDT is global to the whole system. So a LDT entry is the right place to store your user-program's segments while the GDT will usually hold kernel segments, TSSs and LDTs.

A selector is just an index in one of the table. for instance, setting DS=0x10 means that you want to use the segment described by the 3rd entry of the GDT, ES=0x24 means the fifth entry of the current LDT, etc.

when you load a selector in a segment register, the CPU automatically loads some shadow-registers with the content of the descriptor (warning, this means changing the GDT content will *not* affect any loaded descriptor until you refresh them!)

Gates are some mechanism to setup special entry point to more priviledged code. For instance, your user program cannot access the kernel code, but you can setup a gate that will send it to KERNEL_CODE:fork(), another one to KERNEL_CODE:exit(), etc.
You basically need gates for your IDT. Having gates directly in GDT/LDT is feasible, but usually forgotten by OS designers because of little portability.

Pype.Clicker wrote:Gates are some mechanism to setup special entry point to more priviledged code. For instance, your user program cannot access the kernel code, but you can setup a gate that will send it to KERNEL_CODE:fork(), another one to KERNEL_CODE:exit(), etc.
You basically need gates for your IDT. Having gates directly in GDT/LDT is feasible, but usually forgotten by OS designers because of little portability.

An idea I came up (but never implemented) with is using the offset of a far call to a call gate to encode the call number. The CPU ignores the offset, and vectors to the descriptor pointed to by the selector, but you could have the handler code disassemble the bytes at CS:EIP and parse the offset field.

However, this method of calling OS functions is restricted to assembly language or some language that supports far pointers in 32-bit code (there aren't any). Therefore, from a C point of view, this method is just as inconvenient as using interrupts for system calls.

Ok, so the segment registers contain selectors which point to the GDT or LDT. And if I want to access a segment (i.e. CS), the CPU looks into the CS, sees the selector, goes to the GDT or LDT, and there finds the phsyical address of the segment.
Right or not?

Ok, if this is right, could s.o. please give me some example code for buidling a GDT/LDT, a IDT and selectors?