I've been struggling with understanding segmentation for some time now. Here's what I know.

There are different types of segments, such as the code segment, data segment, stack segment, and extra segments. In old architectures (286 and below), segments were limited to 64kB and used a segment:offset addressing scheme. In later architectures, the addressing scheme was changed to a selector:offset scheme where the selector would access an entry in a GDT or LDT which would contain the address of the segment and other information.

Here's what I'm confused about. What's the point of having different types of segments? If they can overlap, than there's no point in having separate data and code segments, just one general type of segment both can go in.

Secondly, if the segments specified in the LDT are for specific processes, what are the segments specified in the GDT for?

How are the segment addresses set in the LDT? I've written assembly code before but I've never had to tell the LDT where to find my segments before. Does the kernel handle all of that?

Dani AI

Generated

A concise, practical view that builds on ’s shorthand and answers ’s questions.

Segments exist because the CPU ties semantics and protection to a segment register, not just to an address. CS is used implicitly for instruction fetch, SS for stack operations (with special checks for push/pop/interrupt stack behavior), and DS/ES/FS/GS for data. That implicit usage lets the hardware enforce different rules (execute-only code, read-only data, stack checks, privilege checks). Overlapping segment bases/limits are allowed for flexibility (multiple selectors can point at the same memory region) but the point of distinct types is the different implicit semantics and permissions the CPU applies.

How selectors work (short): a selector is 16 bits — index in bits 3..15, TI in bit 2 (0 = GDT, 1 = LDT), and RPL in bits 0..1. The CPU uses the selector to fetch a descriptor from the chosen table; the descriptor provides base, limit, access/type and privilege fields. So loading a segment register really means “selector → descriptor → base+offset check → linear address” with protection checks along the way.

GDT vs LDT and who sets them: the GDT is the global table the kernel owns (kernel code/data entries, TSS, LDT descriptors, call gates). LDTs are per-task tables (used when per-process custom segments are needed). The kernel creates the LDT in memory, publishes an LDT descriptor in the GDT that points at it, and loads LDTR (only privileged code can do this). User code doesn’t directly write GDT/LDT entries; OSes expose controlled syscalls or APIs if user-level code needs an LDT entry (historically used for TLS on 32-bit x86).

Practical notes: modern OSes usually use a flat model (GDT entries with base=0, 4GB limit) and rely on paging for isolation, so you rarely touch LDT. If you experiment in protected mode, when you get general-protection faults check: selector RPL vs descriptor DPL, present bit, and the descriptor’s limit/granularity. Example of loading a selector (conceptual):

; selector = (index << 3) | (TI << 2) | RPL
mov ax, selector
mov ds, ax

Recommended Answers

All 3 Replies

GDT is for globals. LDT is for locals, and different LDT's are loaded for different process threads.

Here's a link that shows details of how the descriptors are formatted and used.
Scroll down about half way to find what you're looking for.
Hope this helps!

I read it but I still don't understand how they're used...

The different kinds of segments are used in different, specifically optimized ways for different instructions. You can go to the Intel manual for those details (link here:http://www.intel.com/Assets/PDF/manual/253665.pdf). However, I get the feeling that you are less after the nitty-gritty and more interested in the philosophy of why things were designed the way they were.

Here's a brief write-up that covers some of those basics:
http://wiki.osdev.org/GDT_Tutorial

Or, if you prefer a bit more detail: http://www.osdever.net/bkerndev/Docs/gdt.htm

Not sure if this is what you're looking for, but good luck.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.