Nvidia, TLS and __thread keyword -- an observation

[Julian Elischer]

On Tue, 17 Jun 2003, Marcel Moolenaar wrote:

> On Tue, Jun 17, 2003 at 03:02:20PM -0700, Julian Elischer wrote:
> > 
> > 
> > On Tue, 17 Jun 2003, Marcel Moolenaar wrote:
> > 
> > > Guys,
> > > 
> > > In short: Don't bash Nvidia. What they do is not uncommon. Well,
> > > maybe in Open Source environments. So please end this thread,
> > > unless people get constructive.
> > 
> > I think its already ended..
> > 
> > basically:
> > We should alwasy be able to use (on i386) the sam amethods outlined for
> > solaris. 
> > Not quite as quick as those for Linux but more general.
> 

> I'm not sure you understand the issue (I can easily be wrong, I just
> don't see the evidence in your statement).

I understand what is needed from the thread library.
I am asking for input from people who understand the toolchain :-)

> To support the __thread
> keyword, our thread library needs to create the TLS as defined in the
> binary and its dependent shared libraries by virtue of the .tdata and
> .tbss sections/segments, based on the image of the TLS as constructed
> by the RTLD for the initial set of modules (created for the initial
> thread) and amended by TLS space defined in the dynamicly loaded
> libraries; and the TLS has to be created for every new thread at the
> time the thread itself is created.


Geez considerred writing shorter sentences? :-)

there is no reason that all our thread libraries cannot 
set up TLS sections associated with each modile linked.
(Assuming there is a good description as to how it should be done)

The ammending need not be done up front if the dynamic model is used..

> This TLS allocation has to be made
> accessable in accordance with runtime specifications for the supported
> architectures (libthr: i386 & ia64; libkse: i386 currently -- more to
> follow) and in line with the access sequences created by the compiler,
> and using the static relocations known to the static linker and dynamic
> relocations of which the support needs to be added to RTLD.

exactly.
Though, I might add that we don't need to follow the spec exactly.
In the same way that Solaris has an "excepmtion" and has its own
version of the spec we could do so too. It turns out however that the
solaris-x86 spec is very close to what we want and need anyhow.

Libthr and libkse (i386) can be modified to both have the same 
support. The spec requires that %gs:0 is the address of a pointer to
the thread control block (TCB). In kse this is easily achieved
by puting such a pointer at the front of the KSE mailbox. (where %gs
points), and in libthr the pointer points directly to the TCB itself
(as far as I see) and there could be a pointer to itself set there.
for libc_r we could set up %gs to be anything we want as we don't use it
as such..  anyway. the three libraries would stay binarily compatible.
We obviously would need to add code to do teh initialisation of the 
.tdata and .tbss segments as indicated in the doc.
but it all looks doable. (though rather hacky).

> 
> The static TLS model requires the least amount of work: add support
> to allocate the TLS image for every thread creation and point the
> thread pointer to it in a way compatible with the runtime spec.

yes
We can do this.
I disagree however that it requires the LEAST amount of work..

> 
> The dynamic TLS model requires more substantial changes and involves
> RTLD as well. This is the model that requires __tls_get_addr().

By my reading of it,
you can't use the static model alone.
If you have dynamically loaded modules you need to be able to use the
dynamic model.

Anyway that's why I'm asking..
we need to have people who understand the rtld in on the discussion
because we will need to do this.


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