Date: Sat, 10 Jun 2000 14:16:28 -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.1000610140414.7306A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0006102349070.5817-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Jun 2000, Bruce Evans wrote:
> On Sat, 10 Jun 2000, Daniel Eischen wrote:
>
> > On Sat, 10 Jun 2000, Doug Rabson wrote:
> > > The trapframe which is created for syscall is identical to the trapframe
> > > for exceptions and interrupts, its just not fully populated with register
> > > values.
> >
> > On a related subject, the alpha sigcontext is different than the
> > trapframe. This makes implementing {get,set}context slightly more
> > difficult because they have to know which frame is in the machine
> > context. For the new threads architecture (similar to scheduler
>
> It's different on i386's too. It is certain to be different if the
> floating point state is separate and too expensive to save in the
> trap frame. The i386 also has complications for vm86 mode.
I was thinking that the user threads library would handle floating
point state separately. Right now, the threads library only saves
floating point state when a signal occurs. Normal context switches
do not save floating point state; it is only when a thread is
preempted as a result of a signal that the floating point state
is saved.
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?
> > 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).
--
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.1000610140414.7306A-100000>