http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #35 from philip.copeland at oracle dot com 2013-01-11 17:19:06 UTC
---
(Sorry for the delay in getting back to you)
I've multipass recompiled all the affected packages associated with gcc/glibc
over the last day which has taken quite some time, to try and be sure that none
of the support packages are deficient.
Paolo directed me to wade through the test-suites to look for anything odd
about the TLS results,.. and nothing seemed to be untoward until he mentioned
that he didn't see any thread_local tests
A bit of headscratching, initially the thought was that
// { dg-require-effective-target tls } was false,
however { dg-require-effective-target tls } can't be just false, because the
diag-1.C etc tests from the TLS testsuite were run (successfully). I need to
understand what triggers the tls support. It can't be that tls isn't supported
because the base compiler I used
gcc-4.4.6-3
glibc-2.12
can compile up the test program with tls and complete successfully.
The only immediate code difference I see which probably has no impact is that
the older 4.4.6 code uses
61 extern "C" __cxa_eh_globals*
62 __cxxabiv1::__cxa_get_globals() throw()
63 { return get_global(); }
whereas the newer 4.7.2 codebase uses
62 __cxxabiv1::__cxa_get_globals() _GLIBCXX_NOTHROW
(can't immediately tell what _GLIBCXX_NOTHROW expands to or comes from, but
I'll work it out)
This is the test program disassembled at the same point when compiled with
older gcc 4.4.6
(gdb) disassemble
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
0xfffff801001ee760 <+0>: save %sp, -176, %sp
0xfffff801001ee764 <+4>: sethi %hi(0xc00), %o0
0xfffff801001ee768 <+8>: sethi %hi(0), %i0
0xfffff801001ee76c <+12>: sethi %hi(0x12d800), %l7
0xfffff801001ee770 <+16>: call 0xfffff801001ee700
0xfffff801001ee774 <+20>: add %l7, 0x90, %l7 ! 0x12d890
=> 0xfffff801001ee778 <+24>: add %o0, 0x80, %o0
0xfffff801001ee77c <+28>: xor %i0, 0x10, %i0
0xfffff801001ee780 <+32>: call 0xfffff8010031fce0 <__tls_get_addr@plt>
0xfffff801001ee784 <+36>: add %l7, %o0, %o0
0xfffff801001ee788 <+40>: add %o0, %i0, %i0
0xfffff801001ee78c <+44>: rett %i7 + 8
0xfffff801001ee790 <+48>: nop
End of assembler dump.
So tls DID exist and was being used. I think I can assume that tls support
didn't go away for sparc64 in later gcc releases. (I also threw the binary
against readelf -S
[root@localhost ~]# readelf -S /tmp/test | egrep "init|fini|array"
[11] .init PROGBITS 0000000000100608 00000608
[13] .fini PROGBITS 0000000000100980 00000980
so the older fedora 4.4.6 gcc didn't use initfini-array (if it was even an
available option back then)
So this leaves me in the situation of not understanding what nudges gcc into
supporting tls thread_local etc.It's like it's only partially implemented.
(adding testcase snippet attachment)
