From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26839 invoked by alias); 2 May 2012 10:10:20 -0000 Received: (qmail 26827 invoked by uid 22791); 2 May 2012 10:10:19 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 May 2012 10:10:04 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q42A9Jkl005853; Wed, 2 May 2012 12:09:19 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q42A9G4s021744; Wed, 2 May 2012 12:09:16 +0200 (CEST) Date: Wed, 02 May 2012 10:10:00 -0000 Message-Id: <201205021009.q42A9G4s021744@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sourceware.org 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) Subject: Re: Invalid segment resister value on x86_64-windows References: <1335913461-1628-1-git-send-email-brobecker@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00016.txt.bz2 > From: Joel Brobecker > 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!