Re: Rfork'd threads, signals, and LDTs
On Sat, 5 May 2001, Daniel Eischen wrote: On Sat, 5 May 2001, Andrew Gallatin wrote: Daniel Eischen writes: OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... This breaks at least one version of the IBM JDK that I have laying around.. If anything, we may have two errors (at least partially) canceling each other out. I think it needs more work/thought prior to committing. We're still OK with the change to FreeBSDs native signal trampoline though, right? I'll hold off on the Linux emulator changes until we can figure out what the problem is. I was confused about what Linux does. Now I think it only copies %fs to the signal context struct. It loads %fs with USER_DS for the signal handler. It passes the previous (process) value of %gs to the signal handler. (Its early mistake of of switching %fs on every entry to the kernel was moved to FreeBSD.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Mon, 7 May 2001, Bruce Evans wrote: On Sat, 5 May 2001, Daniel Eischen wrote: On Sat, 5 May 2001, Andrew Gallatin wrote: Daniel Eischen writes: OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... This breaks at least one version of the IBM JDK that I have laying around.. If anything, we may have two errors (at least partially) canceling each other out. I think it needs more work/thought prior to committing. We're still OK with the change to FreeBSDs native signal trampoline though, right? I'll hold off on the Linux emulator changes until we can figure out what the problem is. I was confused about what Linux does. Now I think it only copies %fs to the signal context struct. It loads %fs with USER_DS for the signal handler. It passes the previous (process) value of %gs to the signal handler. (Its early mistake of of switching %fs on every entry to the kernel was moved to FreeBSD.) I think the only reason we used %fs instead of %gs was WINE. I think Linux uses %gs for TSD, so if WINE were to ever depend on linuxthreads, one of them would have to change. We can easily switch to using %gs instead of %fs if necessary. I'll make the appropriate change to the Linux emulator. Thanks -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: I think the only reason we used %fs instead of %gs was WINE. I think Linux uses %gs for TSD, so if WINE were to ever depend on linuxthreads, one of them would have to change. At least on Red Hat 7.0 (glibc-2.1.92-14), Linux does not use a segment register to find TSD. It aligns all stacks at a multpile of 2MB and then does bit ops on the current stack pointer to find a thread control block at the base (highest address) of the stack. There is an alternate implementation in that version of glibc which uses %gs to find TSD. However, it is not used in this version of Linux. I don't know whether it's used in other versions or not. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Mon, 7 May 2001, John Polstra wrote: In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: I think the only reason we used %fs instead of %gs was WINE. I think Linux uses %gs for TSD, so if WINE were to ever depend on linuxthreads, one of them would have to change. At least on Red Hat 7.0 (glibc-2.1.92-14), Linux does not use a segment register to find TSD. It aligns all stacks at a multpile of 2MB and then does bit ops on the current stack pointer to find a thread control block at the base (highest address) of the stack. There is an alternate implementation in that version of glibc which uses %gs to find TSD. However, it is not used in this version of Linux. I don't know whether it's used in other versions or not. I was looking at our linuxthreads port and noticed some %gs fiddling. If linuxthreads wants to allow POSIX semantics for specifying thread stack allocation, they'll have to stop relying on stack alignments for TSD. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: I was looking at our linuxthreads port and noticed some %gs fiddling. If linuxthreads wants to allow POSIX semantics for specifying thread stack allocation, they'll have to stop relying on stack alignments for TSD. Agreed. It appears that they use %gs if it is determined (at glibc build time) that the target Linux kernel is new enough (2.3.99) to support it. The Red Hat 7.0 kernel is 2.2.16. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Sat, 5 May 2001, Andrew Gallatin wrote: Daniel Eischen writes: OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... This breaks at least one version of the IBM JDK that I have laying around.. If anything, we may have two errors (at least partially) canceling each other out. I think it needs more work/thought prior to committing. We're still OK with the change to FreeBSDs native signal trampoline though, right? I'll hold off on the Linux emulator changes until we can figure out what the problem is. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
Daniel Eischen writes: We're still OK with the change to FreeBSDs native signal trampoline though, right? I'll hold off on the Linux emulator changes until we can figure out what the problem is. Yes, I was just commenting on the linulator patch you posted. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
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
Re: Rfork'd threads, signals, and LDTs
On Fri, 4 May 2001, Bruce Evans wrote: On Wed, 2 May 2001, Daniel Eischen wrote: On Wed, 2 May 2001, Bruce Evans wrote: 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. OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... -- Dan Eischen Index: linux/linux_sysvec.c === RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v retrieving revision 1.78 diff -u -r1.78 linux_sysvec.c --- linux/linux_sysvec.c2001/05/01 08:12:52 1.78 +++ linux/linux_sysvec.c2001/05/04 22:49:41 @@ -338,8 +338,6 @@ regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; regs-tf_es = _udatasel; - regs-tf_fs = _udatasel; - load_gs(_udatasel); regs-tf_ss = _udatasel; } @@ -472,8 +470,6 @@ regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; regs-tf_es = _udatasel; - regs-tf_fs = _udatasel; - load_gs(_udatasel); regs-tf_ss = _udatasel; } To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
Daniel Eischen writes: OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... Well, they've never worked perfectly, by any means. Perhaps this will improve the stability problems people have been reporting with the various linux jdks under FreeBSD/i386. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Rfork'd threads, signals, and LDTs
Why are %fs and %gs set back to default (_udata_sel) when posting signals? I am planning on using %fs for TSD/KSD and want it to be valid in signal handlers. A test program is at: http://people.freebsd.org/~deischen/test_tsd.c Compile it with -DDEBUG on an unpatched kernel to show more details. 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; } -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
