Subject: Re: Powerpc signal handler with floating point registers
To: None <port-powerpc@NetBSD.org>
From: Doug Graham <email@example.com>
Date: 03/01/2005 15:14:12
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 <firstname.lastname@example.org> 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
> 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.