Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jun 2003 22:20:10 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        Julian Elischer <julian@elischer.org>
Subject:   Re: Implementing TLS: step 1
Message-ID:  <20030620052010.GC28472@dhcp01.pn.xcllnt.net>
In-Reply-To: <Pine.GSO.4.10.10306200105140.23-100000@pcnet5.pcnet.com>
References:  <20030620041234.GA28472@dhcp01.pn.xcllnt.net> <Pine.GSO.4.10.10306200105140.23-100000@pcnet5.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 20, 2003 at 01:08:46AM -0400, Daniel Eischen wrote:
> > > set_mcontext() implemented in machdep.c, though.  It looks
> > > like you do (although nothing is done with clear_ret in
> > > get_mcontext()).
> > 
> > We cannot do anything with clear_ret, because it's based on
> > assumptions that don't hold in ia64.
> 
> How do return values from syscalls get passed back?

trapframe, as normal. The point is that return registers are not
part of the context and are not saved in the trapframe on entry
to the kernel. The trapframe basicly contains garbage that we don't
save. Hence, clearing is meaningless.

> > BTW: there's no race that can't be plugged if TP doesn't point
> > to the mailbox. All we need is an atomic compare-exchange and
> > a retry loop...
> 
> Ok, the only problem might be something being deallocated
> out from under you.  For instance, a KSE goes away (gets
> deallocated) while your thread is continued on another
> KSE and you are still dereferencing something that may no
> longer be valid.

But isn't that a generic problem and not specific to whether the
thread pointer points to the curthread mailbox?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030620052010.GC28472>