Re: Invalid segment resister value on x86_64-windows

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Tue,  1 May 2012 16:04:19 -0700
> 
> Hello,
> 
> One of our customers noticed that GDB was displaying invalid values
> for the ss & gs register.  It's obviously invalid because the value
> was wider than the registers' size (16 bits). I noticed that the XML
> files define these register as being 32bit, which I am assuming was
> an oversight (?).

Not really an oversight.  While the segment registers are 16-bit,
they're pushed on the stack as 32-bit values (or 64-bit values in
"long" mode).  That's probably why most OSes make them available that
way, and this was carried over into the design of GDB.  In that sense
it was an oversight that they were not widened to 64-bit when we added
amd64 support.

> As a result of the 32bit size, GDB was reading the value of these
> registers as 4 bytes, instead of just 2.

Well, with the current state of affairs, that's a buf in the native
Windows support code ;).

> On GNU/Linux, I did not check the kernel sources, but it appears
> that it was harmless, because the extra bytes were always zero. But
> on some Windows systems, we werent' that lucky.  The extra 2 bytes
> were not null, and thus we ended up with a polluted value.

Linux falls into the "most OSes" category above and makes the segment
registers available as 32-bit or 64-bit values.  Interestingly it
seems that 32-bit Windows does make them available as 32-bit values as
well.  It's 64-bit Windows that is the odd one out here in that it
only provides 16 bits.

> This patch series first regenerates the .c files in features/i386,
> because I noticed a difference between the current files and the
> generated version.  And the second patch changes the size of all
> segment registers to match the size found in the various reference
> manuals.

I'm not sure we can make those changes.  The default layout for the
registers in the target description is chosen such that it is
compatible with the "old" register cache layout used for stubs that
didn't provide a target description.  That layout is still extensively
used by kernel stubs such as the ones in the Linux and NetBSD kernels.
I don't think breaking those would be acceptable, as kernel debugging
is where the segment registers actually matter!