delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/09/09/23:30:34

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019