Date: Fri, 20 Jun 2003 17:08:16 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: threads@freebsd.org Subject: Re: TLS: defining the problem space Message-ID: <Pine.GSO.4.10.10306201702520.23504-100000@pcnet5.pcnet.com> In-Reply-To: <20030620205945.GA19212@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Jun 2003, Marcel Moolenaar wrote:
> On Fri, Jun 20, 2003 at 04:50:45PM -0400, Daniel Eischen wrote:
> > On Fri, 20 Jun 2003, Marcel Moolenaar wrote:
> > > If pthread defines __tls_get_addr() in complete executables and RTLD
> > > defines __tls_get_addr() in shared executables, we have duplicate
> > > definitions for shared executables, with pthread (using dynamic TLS).
> > > Which takes precedence? [answer: RTLD]
> >
> > You can have one __tls_get_addr() be a weak definition, and
> > lib{thr,pthread,c_r} can define a non-weak definition.
>
> Of course. The intend of the question was not to ask how, merely to
> ask which. The answer is not simple, because what if we also have a
> (weak) definition in libc to deal with the complete, without pthread
> and dynamic TLS case (if we want to support that)? Then we have 3
> definitions.
> If both libc and pthread provide weak definitions, then how do we
> guarantee correct binding in the complete, with pthread and dynamic
> TLS case. If libc and RTLD provide weak definitions, then how do we
> guarantee proper binding in the shared, without pthread and dynamic
> TLS case?
libthr,pthread don't have to supply __tls_get_addr(). They
can tell rtld that they are there and pass in a differently
named function (during rtld_lock_init()). So now you're
back down to two definitions. Does that help?
> That's my point of having the problem space defined: we have a lot
> of cases to cover and I want it nailed down and documented before we
> do anything else.
Of course. I'm just offering a possibility. Feel free to
toss it if there are better ways.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306201702520.23504-100000>