From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29579 invoked by alias); 27 Nov 2001 11:19:42 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29521 invoked from network); 27 Nov 2001 11:19:37 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 11:19:37 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id NAA22302; Tue, 27 Nov 2001 13:18:35 +0200 (IST) Date: Fri, 16 Nov 2001 14:55:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: John Hedges cc: gdb@sourceware.cygnus.com Subject: Re: Problem with fld on i686 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00176.txt.bz2 On Tue, 27 Nov 2001, John Hedges wrote: > The st0 register gets -nan and so this is the result of the static_cast. I don't get it: are you saying that the disassembly shows incorrect code? If the code is correct, what does this have to do with the source code (static_cast etc.) from which the assembly instructions were produced? If the code _is_ correct (I think it is), but the results aren't, then the fact that static_cast was used in the C++ program is irrelevant, right? > The problem does not occur when run outside the debugger, nor in a > minimal test program. This suggests that perhaps the FPU state is not saved/restored correctly across task switches. What OS is that? Can you try a different version of the same OS, or some similar but not identical OS? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: John Hedges Cc: gdb@sourceware.cygnus.com Subject: Re: Problem with fld on i686 Date: Tue, 27 Nov 2001 03:19:00 -0000 Message-ID: References: X-SW-Source: 2001-11/msg00283.html Message-ID: <20011127031900.SHu_UjTNb1lHDQpHNkKwA_o79s9Cmn-SLH-siNNASQo@z> On Tue, 27 Nov 2001, John Hedges wrote: > The st0 register gets -nan and so this is the result of the static_cast. I don't get it: are you saying that the disassembly shows incorrect code? If the code is correct, what does this have to do with the source code (static_cast etc.) from which the assembly instructions were produced? If the code _is_ correct (I think it is), but the results aren't, then the fact that static_cast was used in the C++ program is irrelevant, right? > The problem does not occur when run outside the debugger, nor in a > minimal test program. This suggests that perhaps the FPU state is not saved/restored correctly across task switches. What OS is that? Can you try a different version of the same OS, or some similar but not identical OS?