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

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.


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

Reply via email to