Date:	Tue, 06 May 2003 19:38:08 +0300
From:	"Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	djgpp-workers AT delorie DOT com
Message-Id:	<3405-Tue06May2003193807+0300-eliz@elta.co.il>
X-Mailer:	emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to:	<200305051948.h45Jm1LI012342@speedy.ludd.luth.se>
	(ams AT ludd DOT luth DOT se)
Subject:	Re: Yet another try on nan in strto{f,d,ld}
References:	<200305051948 DOT h45Jm1LI012342 AT speedy DOT ludd DOT luth DOT se>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: <ams AT ludd DOT luth DOT se>
> Date: Mon, 5 May 2003 21:48:01 +0200 (CEST)
> 
> A:\>ts3
> FPU CW: 0x00000340.
> float tests:
> Exiting due to signal SIGFPE
> Floating Point exception at eip=00005e21, x87 status=b1a0
> eax=000917ac ebx=00092c2b ecx=0000000c edx=00090f40 esi=000918ad edi=00000006
> ebp=0009171c esp=00091718 program=A:\TS3.EXE
> cs: sel=00bf  base=00116000  limit=0009ffff
> ds: sel=00c7  base=00116000  limit=0009ffff
> es: sel=00c7  base=00116000  limit=0009ffff
> fs: sel=009f  base=000051d0  limit=0000ffff
> gs: sel=00d7  base=00000000  limit=0010ffff
> ss: sel=00c7  base=00116000  limit=0009ffff
> App stack: [00092dc4..00012dc4]  Exceptn stack: [00012d44..00010e04]
>  
> Call frame traceback EIPs:
>   0x00005e21 __modfl+33, file a:/doprnt.c, line 924

Any clues why does it say that __modfl+33 is in doprnt.c?  Is that a
bug in symify/bfdsymify?

> Line 592 is "tmp = modfl(integer * 0.1L , &integer);".
> 
> Worth to note is that the previous modfl() at line 575 worked fine.
> 
> And this is an "objdump -d" of the relevant instructions in modfl:
> 
> 00005e00 <___modfl>:
>     5e00:       55                      push   %ebp
>     5e01:       89 e5                   mov    %esp,%ebp
>     5e03:       83 ec 04                sub    $0x4,%esp
>     5e06:       db 6d 08                fldt   0x8(%ebp)
>     5e09:       8b 45 14                mov    0x14(%ebp),%eax
>     5e0c:       d9 7d fe                fnstcw 0xfffffffe(%ebp)
>     5e0f:       66 8b 55 fe             mov    0xfffffffe(%ebp),%dx
>     5e13:       80 ce 0c                or     $0xc,%dh
>     5e16:       66 89 55 fc             mov    %dx,0xfffffffc(%ebp)
>     5e1a:       d9 6d fc                fldcw  0xfffffffc(%ebp)
>     5e1d:       d9 c0                   fld    %st(0)
>     5e1f:       d9 fc                   frndint 
>     5e21:       d9 6d fe                fldcw  0xfffffffe(%ebp)

AFAIU, the last line above is the one that crashed.  What is the
operand(s) of the FLDCW instruction that crashed, and what is at
0xfffffffe(%ebp) on the stack?

Also, it could be that the actual exception was somewhere else, if
FLDCW is one of the instructions that does the equivalent of FWAIT.
(Or am I confused?)  So it might be a good idea to step with GDB thru
this code and examine the FPU status word after each instruction.
When one of the exception bits in the status word gets set, that's
when the exception actually happens.

> What does "x87 status=b1a0" in the crash message tell us?

It shows the FPU status word.  See the docs of _status87 for the
interpretation of the individual bits.

- Raw text -