[Top] [All Lists]

Re: FP emulator patch

To: "Jun Sun" <>
Subject: Re: FP emulator patch
From: "Kevin D. Kissell" <>
Date: Fri, 17 Aug 2001 00:33:31 +0200
Cc: "Daniel Jacobowitz" <>, "MIPS/Linux List \(SGI\)" <>
References: <018201c12680$8f13e680$0deca8c0@Ulysses> <> <> <01b001c12693$b4920140$0deca8c0@Ulysses> <>
> > 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
> FPU at all.
> This requirement might be a must, because whether clearing
> bit determine which patch we will take in the do_cpu(), when signal
> 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
> 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...


            Kevin K.

<Prev in Thread] Current Thread [Next in Thread>