This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Problem with threaded program
On Sun, Dec 02, 2001 at 01:40:25PM -0500, Andrew Cagney wrote:
> >Greetings,
> >
> >The problem below was originally reported to the Linux Kernel Mailing List.
> >It looks to me to be a gdb problem.
> >
> >I used a freshly compiled and installed copy of gdb-5.1 (configured as
> >"i686-pc-linux-gnu") for this test on a Pentium III 500mhz running the
> >2.4.16 kernel. The same problem happens with gdb-5.0. gdb-4.18 appears to
> >work fine.
> >
> >Here's the test program, test.c:
> >
> >#include <stdlib.h>
> >int main() {
> > char *t="1.0";
> > double d=0;
> > d=strtod(t,(char **)NULL);
> > printf( "%f\n", d );
> > return 0;
> >}
> >
> >Build using "gcc -g -lpthread test.c"; run using "gdb a.out".
> >
> >If you step through the program one line at a time and display variable d
> >after each assignment, the strtod() call seems to return
> >"nan(0x8000000000000)", which is also shown by print().
> >
> >If you restart the program with a breakpoint at printf(), let it run, and
> >display d at the breakpoint, the value shown is "1.000000" which is
> >correct.
> >
> >Is this a defect in gdb, or is my analysis wrong?
>
> Ah, looks like the GDB is corrupting a threaded programs FP registers
> problem.
>
> I'm 99% certain this is in the thread-db/kernel interface that GDB is
> using. Each time this crops up, the problem gets resolved with a
> kernel/library update.
>
> If someone can point out a definitive explination I'll add it to the
> 5.1.1 PROBLEMS file. That way it is at least clearly documented.
>
> The apparent 4.18 -> 5.0 ``breakage'' would have occured because GDB
> switched to using the thread-db/kernel interface.
Well, it happens every time we try to step over an fstpl instruction.
We never call any of the SETREGS or POKE variants, only GETREGS and
GETFPXREGS; I don't see how it could really be our bug.
Note that in the non-threaded case we never call PTRACE_GETFPXREGS at
all. That's:
- an inefficency in the thread code, not surprisingly
- highly suggestive of a kernel bug.
My money's on the kernel, but I don't have time to debug this just now.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer