Date: Tue, 13 Jun 2000 05:32:33 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Doug Rabson <dfr@nlsystems.com> Cc: Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG Subject: Re: Syscalls and execve Message-ID: <Pine.SUN.3.91.1000613051921.22965A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0006130826530.68954-100000@salmon.nlsystems.com>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000613051921.22965A-100000>