On Tue, Mar 01, 2005 at 10:25:49AM -0800, Matt Thomas wrote:
> At 04:37 PM 2/28/2005, Nathan J. Williams wrote:
> >Matt Thomas <matt@3am-software.com> writes:
> >
> >> You need use sigaction and specify SA_SIGINFO.
> >> Only in that case will FP (or AltiVec) registers be preserved.
> >
> >What's the justification for this restriction? I'm not aware of any
> >language in SUSv3 or the PPC ABI that restricts FP code in signal
> >handlers.
> 
> Because that's the way it's been done.  I didn't design it but I can
> understand the reason for it.  Note that sigcontext doesn't have
> space for the FP register set.

I don't see the FP resister set in sigcontext for NetBSD/x86 either,
but I think the FPU state is being preserved there.  At least the test
program that fails on the PPC seems to work on the x86.

The current situation may cause a lot of pain when porting code from
OSes that do save the FP state in a signal handler.  Combined with the
fact that GCC may use the FP registers even for non-FP code, I'd expect
to see bugs turn up that will be intermittent and difficult to debug.

I'm not sure, but I think that one class of apps that may break are
preemptive user-space threads packages.  They probably wouldn't normally
worry about saving the FPU context on a preemption; instead they'd assume
that it is saved in the sigcontext.

--Doug.