Date: Sat, 10 Jun 2000 22:07:15 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Bruce Evans <bde@zeta.org.au> Cc: Doug Rabson <dfr@nlsystems.com>, arch@FreeBSD.ORG Subject: Re: Syscalls and execve Message-ID: <Pine.SUN.3.91.1000610212711.18635A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0006110436340.6476-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Jun 2000, Bruce Evans wrote:
> 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.)
I'd like to avoid saving the FP state (except perhaps for the control
word) when a syscall blocks in the kernel. After a syscall blocks,
the threads library gets an upcall and switches to another thread
without saving the previous (blocked) threads FP state. There is
also the possiblility that the upcall happens in a different
process/processor (when there are multiple cooperating processes).
In this case, the process handling the upcall doesn't have the
FP state available unless the kernel passes it back out.
> > > > 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.
I have library level routines for {get,set,make,swap}context and
modified ucontext_t to add a flag indicating whether the FP regs
were valid or not (perhaps this should be a flag in mcontext_t
on second thought). As for alternative signal stacks, POSIX doesn't
recognize them (at least in the context of pthreads). I was planning
on using the threads own stack to deliver signals. Signals could still
be delivered to the process on a sigalt stack, but the threads
library would add a signal handling frame on the top of the
target threads stack instead of trying to handle the signal on
the signal stack.
--
Dan Eischen
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.SUN.3.91.1000610212711.18635A-100000>