TLS: defining the problem space

[Marcel Moolenaar]

On Fri, Jun 20, 2003 at 05:08:16PM -0400, Daniel Eischen wrote:
> > > 
> > > 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?

Yes, but it is yet again at the level of the implementation. At the
conceptual level there are still 3 different definitions and it's
our job to find the implementation that deals with all the cases
without ambiguity.

Again: we need to keep close to the conceptual level to keep a clear
view of things. Once we sink down to the implementation level, things
get messy pretty quickly. We need to have something to fall back (up)
to if we want to avoid loosing the overview.

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