From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1847 invoked by alias); 2 Dec 2001 23:48:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1811 invoked from network); 2 Dec 2001 23:48:57 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by hostedprojects.ges.redhat.com with SMTP; 2 Dec 2001 23:48:57 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16AgM4-0002Ys-00; Sun, 02 Dec 2001 18:49:04 -0500 Date: Sun, 02 Dec 2001 15:48:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: David Relson , gdb@sources.redhat.com Subject: Re: Problem with threaded program Message-ID: <20011202184904.B7998@nevyn.them.org> Mail-Followup-To: Andrew Cagney , David Relson , gdb@sources.redhat.com References: <4.3.2.7.2.20011202114313.00c40ab0@mail.osagesoftware.com> <3C0A7599.3040902@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0A7599.3040902@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00004.txt.bz2 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 > >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