Date: Mon, 29 Mar 2004 16:26:07 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Doug Rabson <dfr@nlsystems.com> Cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage Message-ID: <Pine.GSO.4.10.10403291625210.15970-100000@pcnet5.pcnet.com> In-Reply-To: <200403292221.00286.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Mar 2004, Doug Rabson wrote: > On Monday 29 March 2004 20:36, Daniel Eischen wrote: > > On Mon, 29 Mar 2004, Doug Rabson wrote: > > > I've been spending a bit of time recently familiarising myself with > > > this TLS stuff and trying out a few things. I've been playing with > > > rtld and I have a prototype patch which implements enough TLS > > > support to let a non-threaded program which uses static TLS work. > > > With a tiny bit more work I can have limited support for dynamic > > > TLS as well (not for dlopen'ed modules yet though). Is there a p4 > > > tree for this stuff yet? I'd like to check in what I have sometime. > > > > > > I've also been looking at libpthread and I can see some potential > > > problems with it. Currently libpthread on i386 uses %gs to point at > > > a struct kcb which seems to be a per-kse structure. This structure > > > contains a pointer to a per-thread struct tcb and this pointer is > > > managed by the userland context switch code. Other arches are > > > similar, e.g. ia64 uses $tp to point at struct kcb. > > > > > > The problem with TLS is that the i386 ABI needs %gs to point at the > > > TLS > > > > There are 2 different methods allowed for the i386 ABI. > > We want to use the other method in which there is an > > additional indirection. The current i386 libpthread > > stuff adheres to this method. > > Surely the GNU TLS ABI is preferable? It generates much smaller code and > needs many fewer relocations. No, we don't want an LDT for every thread and don't want to force a syscall for a thread switch. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10403291625210.15970-100000>