Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com
Cc: gdb-patches@sourceware.org
Subject: Re: Invalid segment resister value on x86_64-windows
Date: Wed, 02 May 2012 10:10:00 -0000	[thread overview]
Message-ID: <201205021009.q42A9G4s021744@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <1335913461-1628-1-git-send-email-brobecker@adacore.com> (message	from Joel Brobecker on Tue, 1 May 2012 16:04:19 -0700)

> 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!


  parent reply	other threads:[~2012-05-02 10:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-01 23:04 Joel Brobecker
2012-05-01 23:04 ` [RFA/commit 1/2] Regenerate the features/i386 target description .c files Joel Brobecker
2012-05-02  6:34   ` Sergio Durigan Junior
2012-05-01 23:05 ` [RFA 2/2] [x86/x86_64] Segment registers are 16 bits long (not 32bits) Joel Brobecker
2012-05-02  0:01 ` [RFA 3/2(+)] Test size of x86/x86_64 segment registers Joel Brobecker
2012-05-02 10:10 ` Mark Kettenis [this message]
2012-05-02 17:57   ` Invalid segment resister value on x86_64-windows Joel Brobecker
2012-05-02 20:45     ` Mark Kettenis
2012-05-02 21:26       ` Joel Brobecker
2012-05-02 21:27         ` Joel Brobecker
2012-05-02 21:50           ` Mark Kettenis
2012-05-02 21:58           ` [WINDOWS/RFC] " Joel Brobecker
2012-05-02 22:10             ` Christopher Faylor
2012-05-02 22:16               ` Christopher Faylor
2012-05-04 18:38               ` checked in: " Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201205021009.q42A9G4s021744@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox