Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 May 2001 06:52:09 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        current@FreeBSD.ORG
Subject:   Re: Rfork'd threads, signals, and LDTs
Message-ID:  <Pine.SUN.3.91.1010502062735.22589A-100000@pcnet1.pcnet.com>
In-Reply-To: <Pine.BSF.4.21.0105021520260.40966-100000@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 May 2001, Bruce Evans wrote:
> On Tue, 1 May 2001, Daniel Eischen wrote:
> 
> > Why are %fs and %gs set back to default (_udata_sel) when posting
> > signals?
> 
> All segment registers are set to a default state so that signal handlers
> have some chance of running when they interrupt code that has changed
> the segment registers to unusual values.

OK.

> 
> > I am planning on using %fs for TSD/KSD and want it to be valid
> > in signal handlers.
> 
> Imagine doing the same thing with %ds, or better yet, %ss.  %ss must
> be set to the default for the kernel to even provide a "normal" stack
> for the signal handler.  Similarly for %ds, except it is possible for
> signal handlers to set up their own %ds as necessary provided both
> the user code and the signal trampoline is written to avoid using %ds
> before initializing it.

Well, we're not using %ds or %ss for TSD.  It was discussed on
-arch some time ago that we would reserve %fs for TSD, so we
really on care about that case.  I threw in %gs because that
was also an option except that WINE used it.

[ patch snipped ]

> There is also the osendsig() case, and corresponding code in several
> emulators.

I don't think we care too much about osendsig() since anything
that uses a new threads library will have to be recompiled
and wouldn't use the old routines.  I think the same is true
for emulators; an application that used the new threads library
wouldn't be running in emulation would it?

> The problem has some similarites to ones for handling floating point
> state.  We should be setting the FPU to a clean state so that signal
> handlers can use floating point.  (We don't do this on i386's because
> signal handlers rarely use floating point and it is difficiult to do
> without pessimizing delivery of all signals.)  OTOH, I believe C99
> says that the floating point environment (things like rounding control)
> is inherited by signal handlers.  This seems to be even more difficult
> to implement on i386's.  Changes in the enviroment made by fesetenv()
> should apply to signal handlers, but temporary ones made by the compiler
> and library functions should not.

So, what if we just make the change for %fs.  Or is there a way
to tell the kernel "Hey, I don't want %fs to be changed" when
setting up the signal handler?  A flag to sigaction sa_flags?

The other option is for the userland signal handler to fetch
the value for %fs out of the sigcontext^Wucontext and manually
set it.  But this gets icky because now the threads library has
to have arch-dependent signal handlers.

-- 
Dan Eischen

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" 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.1010502062735.22589A-100000>