Re: FP emulator patch

["Kevin D. Kissell" <kevink@mips.com>]

> > We've had a lot of messages crossing here, but please
> > explain yourself here why clearing used_math helps in
> > this case.  If, as has been proposed, the current
> > thread does not own the FPU, and thus CU1 is not
> > enabled, the FPU switch mechanism should kick in
> > during the signal handler regardless. The signal
> > handler will inherit the thread's FPU state from
> > the thread context, and will muck with it, but
> > if, as has been noted, the sigcontext has
> > been loaded from the thread context before
> > the handler is dispatched, and is restored after
> > the handler executes, we're fine.  The only thing
> > I can see that clearing used_math would achieve
> > would be to guarantee the signal handler a virgin
> > FPU context.
>
> Yes, that is somewhat the purpose.  Essentially we want to see, at the
> beginning of a signal handler execution, the process appears to have not
used
> FPU at all.
>
> This requirement might be a must, because whether clearing
current->used_math
> bit determine which patch we will take in the do_cpu(), when signal
handler
> uses FPU for the first time.  See the code below.
>
>         if (current->used_math) {               /* Using the FPU again.
*/
>                 lazy_fpu_switch(last_task_used_math);
>         } else {                                /* First time FPU user.
*/
>                 init_fpu();
>                 current->used_math = 1;
>         }
>         last_task_used_math = current;
>
> Clearly the second path is logically the correct one.

Not really.  See below.

> BTW, do I see another bug here in do_cpu()?  It seems that before we call
> init_fpu(), we should check last_task_used_math.  If it is not NULL, we
should
> save the FP state to the last_task_used_math.  Hmm, strange ...

Strange indeed.  And note that if the code were correct, your
surmise about the init_fpu() path being "logically the correct"
one would no longer be true - we'd be saving the FPU state of
the current process for no good reason.

The more I look at the FPU management code, the more I marvel
that it even gives an appearance of working...

            Regards,

            Kevin K.