strange error when accessing TLS data
kamal
I have a library with code :-
----------
__thread int x;
void f()
{
if (x)
...
}
----------
main() declares the variable as
extern __thread int x;
and sets it to 1.
when I access the variable from within the library, I get this error:-
----------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x0089fbf2 in ___tls_get_addr_internal () from /lib/ld-linux.so.2
(gdb) where
#0 0x0089fbf2 in ___tls_get_addr_internal () from /lib/ld-linux.so.2
if I print the value of X, before hitting the fault, i get this error
(gdb) p x
Cannot find thread-local storage for Thread 0xb7f8e6e0 (LWP 9151),
shared library <lib name>
generic error
(gdb)
----------------------------------------
when i compiled the same code standalone outside of my build
environment, it worked fine. Is there a particular compiler option
that triggers this error. Machine details are:-
----------
# uname -a
Linux <machine name> 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST
2008 i686 i686 i386 GNU/Linux
[root@bg-apps-168 trunk]# gcc --ver
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --
disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-
gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
--------------
thanks
-kamal
David Schwartz
> when i compiled the same code standalone outside of my build
> environment, it worked fine. Is there a particular compiler option
> that triggers this error. Machine details are:-
You need to follow your platform's directions. Whatever told you that
your platform supported the "__thread" storage class should have also
told you how to get that support.
If your platform is GCC/ELF, see this document:
http://people.redhat.com/drepper/tls.pdf
DS
kamal
> On Oct 20, 3:39 am, kamal <kama...@gmail.com> wrote:
>
> > when i compiled the same code standalone outside of my build
> > environment, it worked fine. Is there a particular compiler option
> > that triggers this error. Machine details are:-
>
> You need to follow your platform's directions. Whatever told you that
> your platform supported the "__thread" storage class should have also
> told you how to get that support.
>
> If your platform is GCC/ELF, see this document:http://people.redhat.com/drepper/tls.pdf
>
yes -it is gcc/elf. Do I need to do something on i386 to enable
dynamic tls (assume that is required for dynamically loaded
libraries)?
thanks
-kamal
> DS
kamal
>
> > when i compiled the same code standalone outside of my build
> > environment, it worked fine. Is there a particular compiler option
> > that triggers this error. Machine details are:-
>
> You need to follow your platform's directions. Whatever told you that
> your platform supported the "__thread" storage class should have also
> told you how to get that support.
>
I think the support is experimental and method to ensure it works all
the time -is not present. pthread_[g/s]etspecific() is the published
POSIX interface to handle TLS. Why doesn't POSIX standardize on
__thread?
thanks
-kamal
Dave Butenhof
> On Oct 20, 4:22 pm, David Schwartz <dav...@webmaster.com> wrote:
>> On Oct 20, 3:39 am, kamal <kama...@gmail.com> wrote:
>>
>>> when i compiled the same code standalone outside of my build
>>> environment, it worked fine. Is there a particular compiler option
>>> that triggers this error. Machine details are:-
>> You need to follow your platform's directions. Whatever told you that
>> your platform supported the "__thread" storage class should have also
>> told you how to get that support.
>>
>
> I think the support is experimental and method to ensure it works all
> the time -is not present. pthread_[g/s]etspecific() is the published
> POSIX interface to handle TLS. Why doesn't POSIX standardize on
> __thread?
Because that's a LANGUAGE KEYWORD, not an API. It's out of scope for
POSIX. They have no way to say it, and no way to make anybody listen if
they tried. That's why POSIX has the thread specific data API that it
has; it was the best we could do in an API.
ISO C and C++ can standardize that feature -- once they understand the
concept of threads in the first place. C++ 0x is working on that now,
for release soon. ISO C still has, and for the immediately foreseeable
future will continue to have, no concept at all of threads and therefore
no scope to handle a feature like thread specific data.
But standardization will remain complicated by some of the same issues
vaguely hinted at by the answers here. Actual implementations, though
there are many, and with certain core similarities, vary greatly in the
detailed semantics. A lot of this goes to how much intelligence the
linker and loader have to resolve the new class of data. Some can handle
static linking against shared libraries, but not dynamically loaded
libraries (dlopen); others can, but have restrictions on how many
instances of TLS data can appear, or in references across link units
(particularly when one is dynamically loaded). There's really no formal
standard, at language or API level, that covers enough of the object
format, tools, and runtime environment to close all of the loopholes.
kamal
that, I believe is a case of what kind of threading model the loader
supports (DTLS/static TLS). The class of data to be resolved remains
the same -regardless of whether library is statically linked or dlopen
()'ed. HP-UX parisc 32-bit supports static TLS only, but pa64 and ipf
support DTLS, wherein a dtv is setup for DTLS as opposed to fixed
block allocation for static TLS.
For __thread to be implemented universally on a platform, you will
need to define a new relocation type which is emitted into the ELF
file, when a library is created. Otherwise, it will remain a language
feature.
regards
-kamal