Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Apr 2003 11:12:12 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: patch for %gs saving
Message-ID:  <Pine.BSF.4.21.0304111111550.99022-100000@InterJet.elischer.org>
In-Reply-To: <Pine.GSO.4.10.10304110846410.12636-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Fri, 11 Apr 2003, Daniel Eischen wrote:

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

they should not touch %gs


> 
> -- 
> Dan Eischen
> 
> _______________________________________________
> freebsd-threads@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304111111550.99022-100000>