Date: Fri, 11 Apr 2003 08:48:58 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: David Xu <davidxu@viatech.com.cn> Cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving Message-ID: <Pine.GSO.4.10.10304110846410.12636-100000@pcnet1.pcnet.com> In-Reply-To: <001901c3000c$b72c57d0$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Apr 2003, David Xu wrote: > ----- Original Message ----- > From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> > To: "David Xu" <davidxu@freebsd.org> > Cc: <freebsd-threads@freebsd.org> > Sent: Friday, April 11, 2003 1:55 PM > Subject: Re: patch for %gs saving > > > > On Fri, 11 Apr 2003, David Xu wrote: > > > Here is the patch for kernel to save %gs, > > > it works well on my machine. > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > Thanks, I'll give it a go. > > > > > Daniel, is this the reason in your libpthread > > > patch that doesn't use getcontext syscall ? > > > > No, we already had userland versions of getcontext() > > so I simply reused them to avoid the system call. > > That's why THR_GETCONTEXT is a macro; it can be > > defined to be getcontext() for those archs that > > don't have userland versions and want to use the > > system call instead. > > > > Note that we still need userland versions of > > _thread_switch() and _thread_enter_uts() anyways, > > so writing a userland [gs]etcontext() is probably > > pretty simple once you have those. > > > > Plus, when you get a context in order to make a > > context for a new thread, you still can't rely on > > %gs because it may be scheduled on another KSE or > > the thread could be a scope system thread in which > > case it be scheduled in another KSEG. So the current > > %gs isn't necessarily correct for a new thread. > > > > Hmm, this raises a good point. Once you set up a > > thread to run a signal handler, the %gs register has > > already been set. We have to be sure that the > > interrupted context and the thread's new (signal) > > context both have the same %gs and that it runs on > > the correct KSE. Either that, or we have to be able > > to change the contexts to be the correct %gs before > > running the thread and invoking the handler. > > > > I think those code shouldn't touch %gs, these includes > _thread_switch(), _thread_enter_uts(), they don't know > there is a %gs register. Execept kse_entry(), when first > time an upcall is made, it sets %gs to its own LDT, I > think you have already done this, but _thread_switch(), > and _thread_enter_uts() might be change to not touch %gs. getcontext() and setcontext() still touch %gs though. If an application uses those functions and they are used in a thread once while it is on one KSE and another time while it is on a different KSE, then %gs gets hosed. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304110846410.12636-100000>