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 T

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 hav

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

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

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 linu

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: se

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... >

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... > This breaks at least one version of the IBM JDK that I h

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. Per

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 >

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

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 c

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

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 detai