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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to