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.
> > 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
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message