Date: Fri, 20 Jun 2003 13:59:45 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Daniel Eischen <eischen@vigrid.com> Cc: threads@freebsd.org Subject: Re: TLS: defining the problem space Message-ID: <20030620205945.GA19212@dhcp01.pn.xcllnt.net> In-Reply-To: <Pine.GSO.4.10.10306201647360.20305-100000@pcnet5.pcnet.com> References: <20030620204314.GA19111@dhcp01.pn.xcllnt.net> <Pine.GSO.4.10.10306201647360.20305-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
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.
> BTW, we can probably drop libc_r from the picture (mark it
> for deprecation).
Yay! :-)
--
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?20030620205945.GA19212>