floating point exception status not inherited by exec

[James Salter]

In article <240 at samna.UUCP> jeff at samna.UUCP () writes:
>In article <795 at s7.Morgan.COM> amull at Morgan.COM (Andrew P. Mullhaupt) writes:
>>I need to preserve the state of the floating point exception mask
>>across an exec(). Experiments show that the exception mask and the
>>sticky bit status seems to be preserved across fork() (i.e. is
>>inherited by a child) but when exec is invoked, the exceptions may
>>change. This has ummm - 'unpleasant' consequences. Note that it
>>is not sufficient to work at the level of SIGFPE, but it is actually
>>required to specify the floating point exception mask and sticky bit
>>status to different values than the (otherwise sensible) defaults.
>
>Hmm, I'm fairly sure that the "sticky bit" ordinarily refers to the bit in
>the file permissions which causes an executable to hang around in
>the swap space even when it's not in use.  I don't think anyone would
>want this inherited across an exec (Imagine putting the sticky bit on
>your shell and having it inherited across exec's - pretty soon you'd
>run out of swap as every single program in /bin, /usr/bin, /usr/ucb, etc.
>gets sucked into swap).  I think you're referring to something other
>than the sticky bit.

No, he was right in what he said.  The exception status on the 387 (or
emulated 387) is a 16-bit register which contains the status of various
attributes of the 387, including (in the low 6 bits) the status of
floating-point exceptions.  This 6 bits are "sticky" and refer to the fact
that they are not cleared upon the next floating-point instruction unless
that instruction is one of (FINIT, FCLES, FLDENV, FSAVE, and FRSTOR).

This sticky-ness allows one to check for floating-point operations which
cause exceptional conditions to occur (Divide-by-zero, NaNs, etc...).  It
can be difficult to determine the exact instruction if there are many
floating-point operations occuring, but it's a good start.

The sticky-ness he is referring to has nothing to do with keeping files
in swap space.

>As for the exception mask, I think it's only fair to a process being
>exec'd that it know that the floating point chip is in some reasonably
>well-defined state when it begins execution - I'd suspect that's why
>it's being re-initialized.

True.  Though more likely whatever is being execed is just screwing up
the status without caring what's in it.

>If you really need the exception mask to
>be set a certain way, why not pass the state to the new process as
>an argument and let the new process set the exception mask to the
>desired value.

No.  He wanted the exception saved "across" the exec(), not within the
exec().  There is no reason to pass any new parameters in.  Code such
as the following will suffice (assuming I haven't misinterpreted something):

	save_status = fp_get_status();
	....
	.. code involving exec() ..
	....
	(void) fp_restore_status(save_status);

where fp_get_status, and fp_restore_status are small machine language
routines.

>Jeff

jim/jsalter   IBM AWD   T465/(415)855-4427    VNET: JSALTER at PALOALTO
UUCP: ..!uunet!ibmsupt!jsalter               Disc: Any opinions are mine.
IP: ibmsupt!jsalter at uunet.uu.net                 "PS/2 it, or DIE!"