From owner-freebsd-current Tue May 1 22:57: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0E26137B423 for ; Tue, 1 May 2001 22:56:59 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA23102; Wed, 2 May 2001 15:56:51 +1000 Date: Wed, 2 May 2001 15:55:43 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Daniel Eischen 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 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. > This following seems to fix it. Any reason it would cause > problems? > > Index: machdep.c > =================================================================== > RCS file: /opt/FreeBSD/cvs/src/sys/i386/i386/machdep.c,v > retrieving revision 1.447 > diff -u -r1.447 machdep.c > --- machdep.c 2001/04/27 19:28:19 1.447 > +++ machdep.c 2001/05/01 22:20:52 > @@ -745,8 +745,6 @@ > regs->tf_cs = _ucodesel; > regs->tf_ds = _udatasel; > regs->tf_es = _udatasel; > - regs->tf_fs = _udatasel; > - load_gs(_udatasel); > regs->tf_ss = _udatasel; > } There is also the osendsig() case, and corresponding code in several emulators. 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message