From owner-freebsd-arch Sat Jun 10 11:16:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3FFBB37BEFE for ; Sat, 10 Jun 2000 11:16:47 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA08510; Sat, 10 Jun 2000 14:16:28 -0400 (EDT) Date: Sat, 10 Jun 2000 14:16:28 -0400 (EDT) From: Daniel Eischen To: Bruce Evans Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: Syscalls and execve In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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