Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Jan 2002 09:12:50 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, <arch@FreeBSD.ORG>
Subject:   Re: Request for review: getcontext, setcontext, etc
Message-ID:  <20020108085619.D2475-100000@gamplex.bde.org>
In-Reply-To: <Pine.SUN.3.91.1020107160532.22099B-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jan 2002, Daniel Eischen wrote:

> On Tue, 8 Jan 2002, Bruce Evans wrote:
> > On Mon, 7 Jan 2002, Dan Eischen wrote:

> The threads library uses an alternate signal stack; you are probably
> overrunning it.  I've got patches under review to get rid of the
> alternate signal stack so that signals occur on the stack of the
> currently executing thread.

That makes sense.  Is signal handling required to be "normal" in the
POSIX threads library?  If so, then the implementation can't use an
alternate signal stack like this.

> > > We do this in libc_r right now.  When a signal is caught, we use fnsave
> > > to save the FP regs to the ucontext area
> >
> > But this tends to give the trap to load the state from kernel memory so
> > that userland can save it back to user memory.  The trap may be more
> > efficient than a syscall, but that's partly because syscalls are more
> > pessimized.  A single syscall to save the entire ucontext may be more
> > efficient.
>
> fnsave is only used during signals, so the trap wouldn't occur for
> normal thread switches due to yielding or blocking conditions.

I don't see how that can work.  The kernel switches FP in precisely the
opposite case.

> > > (knowing the kernel doesn't
> > > do it for us -- shouldn't it be saving the FP regs?).  We remember
> >
> > Yes.  Use of FP in signal handlers currently corrupts the FP state of
> > whatever was interrupted (on i386's).
>
> Where in the kernel should they get saved (got any patches ;-))?

At most ones that I don't like, in saved mail :-).  See the alpha
[o]sendsig() and [o]sigreturn() for approximately where and how they
should be saved.

Bruce


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?20020108085619.D2475-100000>