Date: Sun, 11 Jun 2000 04:59:43 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Daniel Eischen <eischen@vigrid.com> Cc: Doug Rabson <dfr@nlsystems.com>, arch@FreeBSD.ORG Subject: Re: Syscalls and execve Message-ID: <Pine.BSF.4.21.0006110436340.6476-100000@besplex.bde.org> In-Reply-To: <Pine.SUN.3.91.1000610140414.7306A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Jun 2000, Daniel Eischen wrote:
> On Sat, 10 Jun 2000, Bruce Evans wrote:
>
> A question I've been wanting to ask is: When a system call is
> made, can we assume that the floating point registers are still
> needed after return from the system call?
I'm not sure what you mean by "needed". On i386's, the FP registers
aren't guaranteed to have any particular values on return from a
function that doesn't return an FP value, in particular for syscalls
(except the control word must be preserved except by functions that
are supposed to change it, and the status word and tag word must not
be changed significantly). Syscalls on i386's don't change any of
the FP state in practice. (After a context switch, the physical
state may have changed on return from a syscall, but applications
can't tell because they see a virtual state.)
> > > activations), the context of threads that become unblocked in
> > > the kernel is passed out to the user threads library. I want to
> > > add {get,set}context as library routines and use them to handle
> > > both signal contexts and trapframes as passed out of the kernel.
> >
> > I don't see how they can be implemented as pure library routines,
> > since they will have to get and set kernel state.
>
> Why? They don't now (except for getting/setting the signal mask
> which can be totally avoided).
There is that, and maybe the FP state (or a kernel flag that tells you
where the FP state is saved), and the alternative signal stack. On
second thoughts, I guess there is no problem with the FP state for
the current process -- a process should be able to see its own state
using machine instructions. It is quite different from kernel state
like the signal mask and the altstack -- these must be tracked by
adding a layer to the syscalls that set them.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006110436340.6476-100000>