Bug 27886 - static thread_local on aarch64 are broken in gdb
Summary: static thread_local on aarch64 are broken in gdb
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: threads (show other bugs)
Version: 10.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-18 14:36 UTC by Avi Kivity
Modified: 2024-02-29 19:14 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2024-02-29 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Avi Kivity 2021-05-18 14:36:08 UTC
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.
Comment 1 Andrew Pinski 2021-09-19 02:41:41 UTC
I suspect this due to GCC bug 97344 (which in turn needs binutils support PR 28351).
Comment 2 Andrew Pinski 2024-02-29 05:38:51 UTC
.
Comment 3 Tom Tromey 2024-02-29 18:03:10 UTC
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.
Comment 4 Andrew Pinski 2024-02-29 19:07:42 UTC
(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.