From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: SIGALRM signal handler doesn't save FPU state
Date:	Mon, 09 Sep 2002 22:12:09 CDT
Organization:	Rice University, Houston TX
Lines:	23
Message-ID:	<3d7d6309.sandmann@clio.rice.edu>
References:	<q78f9.1851$Yc7 DOT 106506 AT newsfep2-gui>
NNTP-Posting-Host:	clio.rice.edu
X-Trace:	joe.rice.edu 1031627769 8197 128.42.105.3 (10 Sep 2002 03:16:09 GMT)
X-Complaints-To:	abuse AT rice DOT edu
NNTP-Posting-Date:	10 Sep 2002 03:16:09 GMT
X-NewsEditor:	ED-1.5.9
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> I have a program that uses setitimer to raise periodic SIGALRM signals.  The
> ANSI C/C++ spec guarantees very little about what can be done in a signal
> handler.  However, I've discovered that djgpp 2.03 / gcc 3.10 don't
> save/restore the FPU state across an async signal handler.  Consequently if
> the foreground and the signal handler both execute simple floating points
> ops (like multiply) then the foreground routine can be trashed.

Not all systems have FPUs.  The save/restore instructions are expensive,
and even more expensive if they must be emulated.  Floating point 
calcs in a signal handler are very rare.  So adding this would put a big
burden on machines which can least afford it.
 
> I've added some inline assembler (fnsave/frstor) around my signal handler to
> solve this.

Good, I think this is the right thing to do.

> Perhaps the FAQ could be updated to include this info or even
> better if libc could include this for async signals.

I'd vote yes for documentation (info libc someplace).  No for FAQ, since
it's the first time it's come up that I know about, and Eli's busy :-)

- Raw text -