Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Apr 2003 17:28:30 +0800
From:      "David Xu" <davidxu@viatech.com.cn>
To:        "Daniel Eischen" <eischen@pcnet1.pcnet.com>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: patch for %gs saving
Message-ID:  <001901c3000c$b72c57d0$f001a8c0@davidw2k>
References:  <Pine.GSO.4.10.10304110135540.23482-100000@pcnet1.pcnet.com>

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

----- Original Message -----=20
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
>=20
> Thanks, I'll give it a go.
>=20
> > Daniel, is this the reason in your libpthread
> > patch that doesn't use getcontext syscall ?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20

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=20
think you have already done this, but _thread_switch(),
and _thread_enter_uts() might be change to not touch %gs.

> --=20
> Dan Eischen




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001901c3000c$b72c57d0$f001a8c0>