🚀 go-pugleaf

Here's a problem I encounter quite frequently (but unfortunately not
reproducibly) when using gdb 4.6 (SPARC, SunOS 4.1.2): sometimes
(especially after evaluating expressions on the command line), gdb seems
to restore the floating point state incorrectly, and after that the
program gets lots of signal 8s.  Here's an example transcript:

GDB 4.6, Copyright 1992 Free Software Foundation, Inc...

[running the program...]

[stopped with ^C, called one of the program's functions by hand]

(gdb) Continuing.

Program received signal 8, Arithmetic exception
0x77394 in elapsedTimer::millisecs (this=0xf7fff390) at incls/../timer.h:37
1: x/i $pc  0x77394 <millisecs__12elapsedTimer+40>:  ldd [%o0+0x288], %f4  
(gdb) ha 8 nopa
Signal	   Stop	Print	Pass to program	Description
SIGFPE (8) Yes	Yes	No	Arithmetic exception
(gdb) Continuing.

Program received signal 8, Arithmetic exception
0x7739c in elapsedTimer::millisecs (this=0xf7fff390) at incls/../timer.h:37
1: x/i $pc  0x7739c <millisecs__12elapsedTimer+48>:  fmovs %f2, %f2
(gdb) Continuing.

Program received signal 8, Arithmetic exception
0xca548 in SICompiler::compile (this=0x15ec9b0) at sic.c:195
1: x/i $pc  0xca548 <compile__10SICompiler+1220>:  st %f0, [%fp+-84]
(gdb) ha 8 nopri nosto
Signal	   Stop	 Print	Pass to program	Description
SIGFPE (8) No	 No	No	Arithmetic exception
(gdb) Continuing.
[program runs for a short while, printing some output, then gets a signal
8 which is caught by the programs signal handler]
Internal error: signal 8 code 196 addr 0x77398 pc 0x773a0.

Note that the inferior got a signal 8 even though gdb was supposed to
suppress it!


I suspect that the problem is with the code evaluating expressions at the
gdb prompt.  That code seems to be fairly unstable on the Sparc (see
second bug report).

-Urs

----------------------------------------------------------------------------
Urs Hoelzle                                              urs@cs.stanford.EDU
Computer Systems Laboratory, CIS 57, Stanford University, Stanford, CA 94305