Lazy binding is not really a feature of TLS variables. Lazy binding is used for function calls, not variable references. TLS variables do support lazy allocation, which is not quite the same thing. It’s true that if an executable refers to a TLS variable, then that variable can not be allocated lazily. But that doesn’t really matter, as the allocation of a TLS variable referenced by an executable is essentially free. It simply becomes part of the executable’s TLS segment.

After went through a couple of TLS related documents, I still have questions. It seems to me that, by default, an executable will use IE model to access external TLS variable. With IE model, an executable can access all TLS variables in shared libraries explicitly linked with that executable. So, I think these shared objects can’t support lazy binding for this executable any more. In order to support lazy binding, either GD model or dlsym() has to be used. Am I right?

Thanks!

Eric

int main() { __thread int i; }

That makes i a local variable in main, which in C is known as an “auto” variable (from the very old but still supported syntax “auto int i;”). A local variable can not be a TLS variable. Or, to put it another way, local variables are always TLS variables, in the sense that they can only be accessed by a single thread. TLS only makes sense when speaking about variables which can be accessed by multiple threads, which means a global or static variable.

When I’m trying to use __thread in an application, I get the following gcc error:

error: function-scope ‘i’ implicitly auto and declared ‘__thread’

(all I did is trying to compile an empty C main with the line ‘__thread int i;’)

Any idea what is wrong ? (I’m using gcc 4.2.3 (Ubuntu 4.2.3-2ubuntu7) on 2.6.24-19 (ubuntu generic x86_64 kernel) on x86_64 platform…

The compile line is just ‘gcc attempt.c’..

Thank you!
~avjo

(PS – I still hope to pre-order you Linkers book one day

Is there any reason at all to prefer the pthread_getspecific/setspecific
library calls over a __thread variable ?

What about embedded systems with relatively old kernels (2.6.10 the
oldest) ?

Thanks!
~avjo

http://sco.com/developers/devspecs/
http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl2a
http://people.redhat.com/drepper/tls.pdf
http://www.lsd.ic.unicamp.br/~oliva/writeups/TLS/RFC-TLSDESC-x86.txt

Do you know of any online page I can read more about
this list of supported keywords ?

Thanks again
~avjo

The ‘@’ keywords are extensions to the existing assembly language. They don’t change the assembly, but they tell the assembler which relocation types to generate for the operand to which they are attached. The supported keywords are: PLTOFF (64-bit only), PLT, GOTPLT (64-bit only), GOTOFF, GOTPCREL (64-bit only), TLSGD, TLSLDM, TLSLD (64-bit only), GOTTPOFF, TPOFF, NTPOFF (32-bit only), DTPOFF, GOTNTPOFF (32-bit only), INDNTPOFF (32-bit only), GOT, TLSDESC, TLSCALL.

The %gs register is a segment register. The x86 supports several segment registers. These days they are generally all set to the same value, but in the 80286 days they were used to select different portions of memory for different parts of the program. %gs:0 means address 0 in the segment addressed by the %gs segment register.