Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Jan 2002 17:26:21 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG
Subject:   Re: Request for review: getcontext, setcontext, etc
Message-ID:  <Pine.SUN.3.91.1020107171944.7228A-100000@pcnet1.pcnet.com>
In-Reply-To: <20020108085619.D2475-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Jan 2002, Bruce Evans wrote:
> 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.

I don't know if you would call it "normal", but POSIX does define
how signals should work in a threaded application.  POSIX also
says that the use of sigaltstack in a threaded application is
undefined, so it seemed like it would be OK for the implementation
to use it.

> > > > 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.

OK, thanks.

-- 
Dan Eischen

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?Pine.SUN.3.91.1020107171944.7228A-100000>