Consider this small C++ program: === begin === struct kk { kk() = default; int x = 1, y = 2, z = 3; ~kk() {} }; namespace a { static thread_local kk v1; thread_local kk v2; void f(int x) { v1.x = v2.y = x; } int g() { return v1.x + v2.y; } } int main() { return 0; } === end === Compiling and linking it with -pthread -O3 -g, gcc and clang, I can examine both a::v1 and a::v2 on x86_64 with these commands: (gdb) start (gdb) p a::v1 (gdb) p a::v2 However, on aarch64, I get (gdb) p a::v1 $1 = <optimized out> (gdb) p a::v2 $2 = {x = 1, y = 2, z = 3} a::v1 is not optimized out, and the problem remains when I add a function that returns a reference to a::v1 (thus forcing the compiler to retain the structure in memory). In a more complicated project, I get a different error for static thread-locals - the type is lost though the address is still visible to gdb. Since both g++ and clang++ yield the same result, I assume the problem is with gdb.
I suspect this due to GCC bug 97344 (which in turn needs binutils support PR 28351).
.
It would be interesting to see the DWARF DIE for 'v1'. Normally these end up with DW_OP_form_tls_address -- which on Linux ends up just calling into libthread_db.
(In reply to Tom Tromey from comment #3) > It would be interesting to see the DWARF DIE for 'v1'. > Normally these end up with DW_OP_form_tls_address -- which > on Linux ends up just calling into libthread_db. Right and DW_OP_form_tls_address requires dtprel relocation support which is not currently there for aarch64, see bug 28351 for the binutils support and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 for the GCC side support. it looks like clang/LLVM will need similar support added too. The ABI does define a dtprel relocation even.