On Wed, 2 May 2001, Daniel Eischen wrote:
> On Wed, 2 May 2001, Bruce Evans wrote:
> > > 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
Someone else might :-).
> -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?
A library running under an emulator might. Non-emulated Linux seems
to pass %fs and %gs to signal handlers unchanged, so there is a precedent
for doing things like you want. Go ahead. The Linux emulator certainly
needs to do it the same as Linux.
> 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.
Setting arch-dependent sigaction flags might be icky too. Add some
later if the default behaviour causes problems.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
