From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4164 invoked by alias); 7 Dec 2001 00:27:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4122 invoked from network); 7 Dec 2001 00:27:52 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 7 Dec 2001 00:27:52 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA08030; Thu, 6 Dec 2001 16:27:50 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id RAA08817; Thu, 6 Dec 2001 17:27:31 -0700 Date: Thu, 06 Dec 2001 16:27:00 -0000 From: Kevin Buettner Message-Id: <1011207002731.ZM8816@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: [PATCH RFA] Fix x86 floating point vs. thread problem" (Dec 6, 7:01pm) References: <1011206234806.ZM8667@ocotillo.lan> <20011206190103.A28378@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz Subject: Re: [PATCH RFA] Fix x86 floating point vs. thread problem Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-12/txt/msg00185.txt.bz2 On Dec 6, 7:01pm, Daniel Jacobowitz wrote: > On Thu, Dec 06, 2001 at 04:48:07PM -0700, Kevin Buettner wrote: > > The patch below fixes the problem reported by David Relson in > > > > http://sources.redhat.com/ml/gdb/2001-12/msg00001.html > > > > An impressive test matrix regarding this bug has been provided by > > Emmanuel Blindauer at > > > > http://manu.agat.net/bug.html > > > > Anyway, the problem is that GDB is computing the fpxregs version of > > the tag value incorrectly. The fpxregs version of the tag value is > > simply a bitmask (of eight bits) which indicate which of the floating > > point registers is in use. i387_fill_fxsave() was incorrectly > > shifting by twice the the number of bits that it should have. > > > > * i387-nat.c (i387_fill_fxsave): Change type of ``val'' from char > > to short so that we don't memcpy() beyond the end of this buffer. > > Also, change shift value used in computing val to account for the > > fact that only eight bits are used. > > Out of curiousity, can you explain what I saw when looking at this? I > found that we never set any fp-related register, and yet when the value > of d was written to memory it was incorrect. Was it not actually yet > written to memory, or was I just mistaken? I was puzzled by that too for a while. I used the version of the test program at Emmanuel Blindauer's page: 1 #include 2 3 int main() { 4 char *t="1.0"; 5 double d=0; 6 d=strtod(t,(char **)NULL); 7 return(0); 8 } Line 6 is comprised of the following instructions: 0x8048493 : call 0x804835c 0x8048498 : add $0x10,%esp 0x804849b : fstpl 0xfffffff0(%ebp) Umm, I guess I'm missing the argument setup, but that's good enough. If you put a break on *main+40, you'll see that a floating point register is in use when you've hit this breakpoint. Anyway... the bug as reported was to put a breakpoint on line 6, and then do a ``next''. IIRC, the ``next'' operation actually singlesteps into the call, places a breakpoint on the call exit, and then singlesteps the instructions at main+40 and main+43. In the course of doing this, GDB fetches and stores the registers many, many times. (Too many times, IMO.) As far as I can tell, it's when GDB hits the step_resume breakpoint at main+40 that the corruption occurs. Kevin