This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFA] Fix x86 floating point vs. thread problem
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