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>