From owner-freebsd-arch  Mon Jan  7 14:12:48 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 30AD537B402
	for <arch@FreeBSD.ORG>; Mon,  7 Jan 2002 14:12:31 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA29625;
	Tue, 8 Jan 2002 09:12:10 +1100
Date: Tue, 8 Jan 2002 09:12:50 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@gamplex.bde.org>
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
In-Reply-To: <Pine.SUN.3.91.1020107160532.22099B-100000@pcnet1.pcnet.com>
Message-ID: <20020108085619.D2475-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

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