Re: [PATCH RFA] Fix x86 floating point vs. thread problem

[Kevin Buettner <kevinb@redhat.com>]

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 <stdlib.h>
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 <main+35>:    call   0x804835c <strtod>
0x8048498 <main+40>:    add    $0x10,%esp
0x804849b <main+43>:    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