Hi,

> - Trying to get SIGFPE and fp{get,set}sticky to work, so powerpc will
>   pass the tests in src/regress. (Having problems with PowerPC FPU
>   semantics vs expected fp{get,set}sticky semantics that I keep
>   meaning to send mail about...)

It just so happens that I had to look into this last week anyway.
(I'm not sure what you mean by "problems with PowerPC FPU semantics
vs expected fp{get,set}sticky semantics", can you explain?)

Anyway, the main problem with SIGFPE and fpsetmask is that the kernel
doesn't have provisions to handle FPU exceptions.  This has to be
implemented in trap.c.  Having done that we need to enable these
exceptions in the MSR.  I'm not sure how this should be done, but
probably the best thing would be to provide a machine specific
system call to set the PSL_FE* bits to the user's liking.
fpsetmask() then would set these bits to ignore if it's parameter
was 0 and to precise exception handling in other cases.

In addition, the fpset* routines should probably be changed to
mask their parameters to the intended bit combinations.

One other thing for fpsetmask: while I can't find a definitive
reference (is there any appropriate standard for this?), SUN's
manual page says that fpsetmask should clear any pending
exceptions before enabling the traps.

Speaking of a reference for these routines, I'm not sure how
the interaction of fpsetmask(), SIGFPE and fpgetsticky() is
supposed to work.  Naively I'd expect to set up a signal
handler, enable the exceptions with fpsetmask(), and, in the
signal handler, look at the exceptions that occured with a
call to fpgetsticky().  However, this doesn't work, as, in
order to avoid a recursive trap, the kernel has to clear
(at least) the enabled exceptions from the FPU status (and
does so in all implementations I was able to test).  In short,
fp[sg]etsticky seems to be valid only for disabled exceptions.
So how is one expected to find out the cause of the call to
the SIGFPE handler?  (I'm currently inclined for an implementation
that provides the exception status as the additional "code"
argument to the signal handler, but this doesn't look as if
it is a standard either).

Anyway, I can provide some code for this, but am currently
unable to test it.  Anyone being able and willing to test
some code, please contact me (preferrably privately).

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800