From: Jun Sun <jsun@mvista.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
"MIPS/Linux List (SGI)" <linux-mips@oss.sgi.com>
Subject: Re: FP emulator patch
Date: Thu, 16 Aug 2001 16:12:24 -0700 [thread overview]
Message-ID: <3B7C5358.59C72108@mvista.com> (raw)
In-Reply-To: 20010816153702.A21978@nevyn.them.org
Daniel Jacobowitz wrote:
>
> On Thu, Aug 16, 2001 at 02:34:45PM -0700, Jun Sun wrote:
> > 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.
>
> Why?
>
> > 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. Why should it get a clean set of FP registers? I think
> the CORRECT thing would actually be for it to have the app's FP
> registers. Changes should not propogate back to the app, that's all.
>
Ah, it seems I need to defend an "obvious" point. :-)
I am from the school which view signal handler as an interrupt context to a
normal process. (In fact, some OSes implement signal handling by using a
separate thread/process). Under this view, it is natural to provide a fresh
new context when a signal handler starts.
In other words, I am thinking in the following semantics: a signal handler
starting execution is equivalent to another process starting execution with
the same address space, except that the original process won't resume until
the "signal handler process" exits.
Thinking from that, I feel we should clear the current->used_math bit.
I think it is not correct for signal handler to inherit the FPU registers. If
it wants to check the register values when the signal happens, it should do so
by examing the signal context.
Apparently a well code signal handler does not depend on whether we clear
current->used_math bit or not, because it should always set a FPU register
before it uses it.
Jun
> > 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 ...
>
> I thought I got all of these... <sigh>
>
> --
> Daniel Jacobowitz Carnegie Mellon University
> MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2001-08-16 23:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-16 18:23 FP emulator patch Kevin D. Kissell
2001-08-16 18:23 ` Kevin D. Kissell
2001-08-16 18:49 ` Pete Popov
2001-08-16 18:53 ` Daniel Jacobowitz
2001-08-16 19:15 ` Jun Sun
2001-08-16 20:40 ` Kevin D. Kissell
2001-08-16 20:40 ` Kevin D. Kissell
2001-08-16 21:34 ` Jun Sun
2001-08-16 22:33 ` Kevin D. Kissell
2001-08-16 22:33 ` Kevin D. Kissell
2001-08-16 22:38 ` Pete Popov
2001-08-16 22:37 ` Daniel Jacobowitz
2001-08-16 23:12 ` Jun Sun [this message]
2001-08-16 23:38 ` Kevin D. Kissell
2001-08-16 23:38 ` Kevin D. Kissell
2001-08-16 19:20 ` Kevin D. Kissell
2001-08-16 19:20 ` Kevin D. Kissell
2001-08-16 20:20 ` Jun Sun
-- strict thread matches above, loose matches on Subject: below --
2002-09-10 11:55 Carsten Langgaard
2001-08-16 22:58 Kevin D. Kissell
2001-08-16 22:58 ` Kevin D. Kissell
2001-08-16 23:14 ` Jun Sun
2001-08-16 23:46 ` Kevin D. Kissell
2001-08-16 23:46 ` Kevin D. Kissell
2001-08-15 12:53 Carsten Langgaard
2001-08-15 18:06 ` Daniel Jacobowitz
2001-08-16 0:05 ` Kevin D. Kissell
2001-08-16 0:05 ` Kevin D. Kissell
2001-08-16 4:20 ` Atsushi Nemoto
2001-08-16 12:35 ` Kevin D. Kissell
2001-08-16 12:35 ` Kevin D. Kissell
2001-08-16 7:07 ` Carsten Langgaard
2001-08-16 4:35 ` Atsushi Nemoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B7C5358.59C72108@mvista.com \
--to=jsun@mvista.com \
--cc=dan@debian.org \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox