Jamie Lokier wrote:
> Jan Kiszka wrote:
>> Jamie Lokier wrote:
>>> Jan Kiszka wrote:
>>>> FS =0000 00000000 00000000 00000000
>>>> LDT=0000 00000000 00000000 00008200 DPL=0 LDT
>>> Both are =0000, but different descriptors - is that right?
>> Good question. My patch only parses to descriptor cache content without
>> evaluating the selector. I guess that 0x00008200 is a leftover from a
>> previous, valid LDT descriptor.
>>
>>> Also I'm thinking the null descriptor doesn't need to show offset and
>>> size:
>>>
>>> FS =0000
>>>
>>> is enough?
>> Yes, makes sense. IOW: stop parsing if selector == 0. Will post an update.
> 
> Hmm.
> 
> Does a real x86 look at the selector value ever (except when loading
> it), or does it base all decisions on the descriptor cache?
> 
> It's an accuracy of emulation thing, as you can legitimately put the
> CPU into states where the descriptor cache and selector values are
> inconsistent, and it does have a well-defined behaviour.

Yeah, there is some truth in this. While you can't load NULL into the
task register e.g., it may still work based on its boot-up cache content.

> 
> If a real x86 always uses the descriptor cache, presumably there
> shouldn't be a leftover value in it when LDT is loaded with 0, and
> perhaps choosing to show a null descriptor should depend on the
> descriptor cache entry rather than the selector value.

Let's don't try to be too clever here (even 0 in all cache fields can
have a meaning in 64-bit mode) and simply keep the output as is.

However, your suggestion led to a nice code cleanup as I folded all
descriptor dumping into a single helper. :)

Jan