TLS: defining the problem space

[Daniel Eischen]

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