Re: FP emulator patch

[Pete Popov <ppopov@pacbell.net>]

Kevin D. Kissell wrote:
> As I wrote last night, it looks to me as if FPU context
> management in signals was broken in all versions and
> proposed patches that I've seen.  The way I see it is this:
> 
> If the current thread "owns" the FPU, we need to save the
> FPU state in the sigcontext and restore it on return.  If
> the signal handler uses floating point, it already has the
> FPU, and can do what it wants with it.  If it doesn't use
> the FPU, then we'll save and restore FPU state for
> nothing, but better safe than sorry.  In either case,
> the current thread retains ownership of the FPU.
> There is no reason to muck with the ownership data
> or the Cp0.Status.CU1 enables, apart from the
> questionable bit of enabling it before the FP context
> save in case it wasn't enabled.  I think that should go
> away, but I don't have time to test exhastively.  In
> any case, CU1 should have it's pre-signal state
> going into the signal handler.
> 
> If the current thread does *not* own the FPU, we don't
> need to save the thread FP state. If the signal handler
> does no FP, so much the better, there's nothing to
> be done.   If the signal handler uses FP, it will acquire 
> the FPU by normal means. The FP context will be saved 
> into the thread context of the previous owner, the signalling 
> thread will acquire the FPU, and the signal handler will do 
> it's FP. On return from the signal, we *must* de-allocate the
> FPU and clear the CU1 bit.  If that's done, and the
> thread (which had not *owned* the FPU prior to the
> signal) starts doing FP again, normal mechanisms
> will cause it's FP context to be restored.  If we don't,
> it will start exectuing with a bogus FP context.
> 
> The code I sketched last night is essentially correct,
> though it used a macro that doesn't exist.  I attach a
> patch relative to the current OSS repository's signal.c.
> The patch includes the stack frame tweak for the FPU
> emulator that was part of previous patches, but which
> is orthogonal to the problem under discussion.  I have
> built a kernel using this code and run 20 simultaneous
> copies of the MontaVista "stressor" program with no
> problems (though I also had the "v1.5" FPU emulator
> code).

I've lost track of all the patches now :-) Can I trouble you to create a 
complete patch of your arch/mips/math-emu, and whatever other files you've 
modifed, against Ralf's tree?

Pete