TLS: defining the problem space

[Marcel Moolenaar]

On Fri, Jun 20, 2003 at 05:05:37PM -0400, Alexander Kabaev wrote:
> On Fri, 20 Jun 2003 13:43:14 -0700
> Marcel Moolenaar <marcel at xcllnt.net> wrote:
> > 
> > Y.  static vs dynamic. This of course refers to the TLS model in use.
> >     A process can have both models in use at the same time!, but only
> >     if the process belongs to a complete binary (ie: you cannot have
> >     the static TLS model in shared executables,
> 
> Unless I am missing something, this is not true. One can have static
> TLS in a dynamically linked binary as long all all modules using static
> access are part of the process startup set of libraries. One cannot
> dynamically load shared libraries compiled with static TLS model, but it
> is OK to link with them.

Ah, yes. True. You can make it work by having the thread pointer point
to the TLS of the startup as well as have them accessable through the
DTV. Excellent point.

> >     but you can have the
> >     dynamic TLS model in complete executables. The big difference
> >     between static and dynamic is the use of __tls_get_addr() to get
> >     the virtual address of a thread local variable (or not).
> 
> __tls_get_addr() use is a characteristic of the TLS model the module has
> compiled in, and not whether or not application is static or dynamic.

Yes. My wording may have been sloppy enough to suggest an implication.
They are correctly identified as different dimensions in the problem
space. That should be considered authoritative.

> > Examples of problems we need to solve are:
> > o  In a complete executable, without pthread and using dynamic TLS,
> >    what defines __tls_get_addr() and how is it defined?
> 
> How about weak libc symbol which will be overridden by rtld definotion? 

My thought as well, but we may also need a definition in the threads
library as well as in rtld. This means that we can have a case in
which we only have weak definitions and thus no guranteed correct
binding.

> > 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]
> 
> Can __tls_get_addr be included only in a static library. All dynamic
> libraries by necessity will have to depend on a declaration provided by
> the rtld then. Otherwise a weak symbol trick can be used as described
> above. This is no different from a case of libc providing dummy dlfcn.h
> stubs today.

That's a possibility. But I don't want to think too much in terms of
implementation at this stage. I want to have a conceptual view as
well as have implementation alternatives. The conceptual view should
help us to resolve conflicts caused by implementation assumptions.

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