Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!spdcc!m2c!frog!john
From: john@frog.UUCP (John Woods, Software)
Newsgroups: comp.unix.questions
Subject: Re: question about signal
Message-ID: <1659@frog.UUCP>
Date: Mon, 5-Oct-87 18:56:00 EDT
Article-I.D.: frog.1659
Posted: Mon Oct  5 18:56:00 1987
Date-Received: Fri, 9-Oct-87 04:42:29 EDT
References: <720001@hpclmar.HP.COM> <4248@udenva.UUCP>
Organization: Superfrog Heaven [ CRDS, Framingham MA ]
Lines: 58
Summary: \

In article <4248@udenva.UUCP>, rneitzel@udenva.UUCP (RICHARD NEITZEL ) writes:
> In article <720001@hpclmar.HP.COM> mar@hpclmar.HP.COM (Michelle Ruscetta) writes:
> > Question about signal():
> >  Should the return from a signal handling routine specified by a call
> >  to signal() go to the instruction which caused the signal, or to the 
> >  instruction immediately following that which caused the signal?
> >  void (*p_my_handler)();
> >  main()
> >  {  
> >     extern void my_handler();
> >     int y = 0;
> >     int x = 3;
> >     p_my_handler = my_handler:
> >     signal(SIGFPE, p_my_handler);    
> >     x = x/y;		      /* should my_handler return to here? */
> >     printf("return from signal\n");  /* or to here? */
> >  }
> 
I would argue that the signal should return to the instruction causing the
problem, if it returns at all.  Presumably, your handler will either fix
up the problem to allow the instruction to complete correctly (e.g., it
would determine that one of the arguments is 0.0, print a message, stuff a
1.0 into the register or temporary, and return), it would bypass the
effects of the instruction and advance the program counter that will be
returned to (e.g., it prints a message, stores an IEEE infinity into the
result of the instruction (register, memory location, whatever), bumps the
PC, and returns), or it prints out an error message, maybe a stack backtrace,
and craps out again with a core dump.

Note that two of these aren't portable things.  Furthermore, they may become
impossible in processors with separate, asynchronous, floating point units
(e.g. the venerable PDP-11), or with lots of internal pipelining:  how does
one "properly" re-do

	divf	fr0,fr1
	inc	r0
	addf	fr1,fr2

if the divf gets an exception AFTER the 'inc r0' has executed?

In short, it is probably easiest to offer to repair damage from an exception
if the exception handler is told which instruction faulted and is allowed
to return to it, but in the *general* case the only useful thing a signal
handler can do in this case is:

my_FPE_handler() {
	fprintf(stderr,"Ah, geez, a floating point exception happened!\n");
	abort();
}

--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
		-- Johnny Hart