VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

What happens when a GDT entry 0 is valid(present bit etc. give valid results and is loadable) and you try to execute, e.g. a MOV DS,0 in protected mode? Will the 80386+ load the descriptor? Or will this always cause a #GP fault, not even loading the descriptor in memory?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Even if it's marked present? Also, why is it sometimes used to store the GDTR? There's the SGDT instruction after all?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 8, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

It doesn't matter if it's present or not. You can't access anything using selector 0 because it's reserved for "this selector is unused but requires an always-available value, (which is zero)".
The memory location to which it points can be used to hold the GDTR so that you can LGT from that location which would be otherwise wasted.

Reply 5 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Why would you want to put a GDTR register's contents at that entry? Is it somehow more convenient to use that location, instead of within normal buffers? It cannot easily be accessed, unless you have the GDTR in another entry encoding a normal data segment that points to the GDT itself?

Btw, one thing I'm also wondering is this: how is the GDT handled in multitasking(and using Paging) environments? It isn't stored during task switches, thus must be Paged in at all processes at the same location in linear memory always? Thus it's in a special location that's accessable from any process running in the OS, no matter what application is running?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 8, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

Since the 0th entry in the GDT is not available for use in protected mode, it's wasted memory unless you put something there, such as the GDTR which happens to fit exactly in that space.
That's really the only reason why you might consider doing it.

As far as how it's used in different environments, that's up to the programmer. You might have multiple GDTs in a fixed location in memory, and just switch between them at will, but it will limit your task count. You might have a single GDT that everyone shares, but you might run out of descriptors. You might have a top-level GDT that is used between task-switches, and perform a dynamic allocation/deallocation of a GDT for each task start/end and then just switch between those.

Reply 7 of 8, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

Why would you want to put a GDTR register's contents at that entry? Is it somehow more convenient to use that location, instead of within normal buffers? It cannot easily be accessed, unless you have the GDTR in another entry encoding a normal data segment that points to the GDT itself?

its convenient. its right there with the gdt. it can be access very easily, by just having a 4gb selector for code/data... like every dos extender ever.

superfury wrote:

Btw, one thing I'm also wondering is this: how is the GDT handled in multitasking(and using Paging) environments? It isn't stored during task switches, thus must be Paged in at all processes at the same location in linear memory always? Thus it's in a special location that's accessable from any process running in the OS, no matter what application is running?

you know what the G in GDT means right? Its global to ring 0 process. gdt has a physical address. gdt cannot be paged to disk. if you paged it to disk, and used its physical memory for something else, cpu would see GDT as being full of garbage and reset, because gdt also contains selectors used by the idt, all exceptions would have invalid address as well.

have you never actually programmed in assmebler or protected mode assembler?

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 8 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

To be honest, never went any further than real-mode assembly on a 286 or 386(MS-DOS) as far as I can remember. All other instructions I've simply learned building the emulator itself. So I at least know what all fields in the tables and CPU do(except undocumented stuff). So essentially, the stuff that's on osdev and various other x86 information websites(also a little bit tought by my father back when I was 10), combined with the information I've learned here on vogons. So other than some simply driver tutorial book I once read(PC Intern book as well as Turbo Pascal 6.0 book back then), I've entirely learned stuff by the tutorials on cplusplus.com(and some PHP tutorials), as well as lots of experimentation by applying stuff in my emulator and other applications I've made(simply ISO reader I've made in high school, EBOOT2ISO, Popstation PSP, UniPCemu and a game I was developing with a friend(not worked on it since I was working on UniPCemu since a long time ago) that's essentially a game version of the Astrotroopers of the Hatsune Miku video( https://www.youtube.com/watch?v=nTWqJ1SSBgA ) but was never finished(another group was creating a version of that game as well).

Although I've started building a little option ROM for the IBM PC adding AT functionality(primarily XT RTC chip) support to the (Generic Turbo) XT BIOS, which wasn't finished yet also ( https://bitbucket.org/superfury/unipcemu_pcxtbios_at/ ). Though the code itself is untested.

Never programmed in protected mode assembler, but I should be able to (know all commands that are used and how they work(except undocumented stuff or badly documented stuff)).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io