From owner-freebsd-current Wed May 2 3:52:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D9B2737B423 for ; Wed, 2 May 2001 03:52:49 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA25527; Wed, 2 May 2001 06:52:10 -0400 (EDT) Date: Wed, 2 May 2001 06:52:09 -0400 (EDT) From: Daniel Eischen To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: Rfork'd threads, signals, and LDTs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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