From owner-freebsd-arch Tue Jun 13 2:35:40 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 234B337BA5F for ; Tue, 13 Jun 2000 02:35:38 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id FAA24198; Tue, 13 Jun 2000 05:32:33 -0400 (EDT) Date: Tue, 13 Jun 2000 05:32:33 -0400 (EDT) From: Daniel Eischen To: Doug Rabson Cc: Bruce Evans , 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 Tue, 13 Jun 2000, Doug Rabson 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 > > 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. > > > > This isn't a big deal, we can just have a different set of routines > > to handle trapframes for the alpha, but if there is an opportunity > > to make trapframes and signal frames consistent (as they are on > > i386)... > > It would be difficult to make trapframe match sigcontext without changing > sigcontext to look more like the current trapframe (which is partly > dictated by PALcode). I don't think the associated cost of changing the > kernel ABI is worth the gain. Also, the fpregs state is totally unneeded > for trapframe since the kernel doesn't disturb the fp state during traps. OK, I've been using a flags word to indicate whether it's a trapframe or a sigcontext. I'm not worried about the fpregs, since they seem to be already flagged as saved or not saved. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message