[Bug threads/27886] New: static thread_local on aarch64 are broken in gdb

[Bug threads/27886] New: static thread_local on aarch64 are broken in gdb

[avi@cloudius-systems.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

            Bug ID: 27886
           Summary: static thread_local on aarch64 are broken in gdb
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: avi@cloudius-systems.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=97344,
                   |                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=28351
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect this due to GCC bug 97344 (which in turn needs binutils support PR
28351).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-02-29
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/llvm/llv
                   |                            |m-project/issues/83466

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[avi at scylladb dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #5 from Avi Kivity <avi at scylladb dot com> ---
Still broken in 2026. Do people just not have bugs on aarch64?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Avi Kivity from comment #5)
> Still broken in 2026. Do people just not have bugs on aarch64?

It sounds like this is more of a binutils/gcc problem than a gdb problem
and that there isn't anything gdb can do about it.

If you disagree, please provide some more information.  I'm going
by comment ##1 and comment #4.  Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[avi at scylladb dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #7 from Avi Kivity <avi at scylladb dot com> ---
I don't have any expertise in this area, so can't agree or disagree. I'll ping
those other bugs too. I'm just surprised there isn't more traffic here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[avi at scylladb dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #8 from Avi Kivity <avi at scylladb dot com> ---
Strangely, the required ABI changes were merged last week:

https://github.com/ARM-software/abi-aa/commit/d455ef1e884fe7a3c4f1e05ed40cdeed9103dea9

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
[ This is with aarch64-linux (Fedora Linux Asahi Remix 42). ]

I.

Let's first look at gcc:
...
$ gcc --version
gcc (GCC) 15.2.1 20251211 (Red Hat 15.2.1-5)
...

Let's compile at -O0, to avoid things being optimized out due optimization:
...
$ g++ test.c -g 
...

We get:
...
$ gdb -q -batch a.out -ex start -ex "p a::v1" -ex "p a::v2"
  ...
$1 = <optimized out>
$2 = {x = 1, y = 2, z = 3}
...

Now let's look at the debuginfo:
...
 <1><99>: Abbrev Number: 11 (DW_TAG_namespace)
    <9a>   DW_AT_name        : a
 <2><a3>: Abbrev Number: 12 (DW_TAG_variable)
    <a4>   DW_AT_name        : v1
    <aa>   DW_AT_type        : <0x2f>
    <ae>   DW_AT_declaration : 1
 <2><ae>: Abbrev Number: 13 (DW_TAG_variable)
    <af>   DW_AT_name        : v2
    <b5>   DW_AT_linkage_name: (indirect string, offset: 0x16): _ZN1a2v2E
    <b9>   DW_AT_type        : <0x2f>
    <bd>   DW_AT_external    : 1
    <bd>   DW_AT_declaration : 1
 <1><dc>: Abbrev Number: 3 (DW_TAG_variable)
    <dd>   DW_AT_specification: <0xa3>
 <1><e1>: Abbrev Number: 3 (DW_TAG_variable)
    <e2>   DW_AT_specification: <0xae>

...

There's no DW_AT_location for v1.

As it happens, also not for v2, but that one is external, and gets special
handling in new_symbol:
...
              /* We do not know the address of this symbol.                     
                 If it is an external symbol and we have type information       
                 for it, enter the symbol as a LOC_UNRESOLVED symbol.           
                 The address of the variable will then be determined from       
                 the minimal symbol table whenever the variable is              
                 referenced.  */
              attr2 = dwarf2_attr (die, DW_AT_external, cu);
...


II.

Now let's try with clang:
...
$ clang++ -v
clang version 20.1.8 (Fedora 20.1.8-4.fc42)
...

Likewise, we have:
...
$ gdb -q -batch a.out -ex start -ex "p a::v1" -ex "p a::v2" 
  ...
$1 = <optimized out>
$2 = {x = 1, y = 2, z = 3}
...

In this case, the debuginfo is:
...
 <1><2b>: Abbrev Number: 2 (DW_TAG_namespace)
    <2c>   DW_AT_name        : (indexed string: 0x3): a
 <2><2d>: Abbrev Number: 3 (DW_TAG_variable)
    <2e>   DW_AT_name        : (indexed string: 0x4): v1
    <2f>   DW_AT_type        : <0x68>
    <35>   DW_AT_linkage_name: (indexed string: 0xb): _ZN1aL2v1E
 <2><36>: Abbrev Number: 4 (DW_TAG_variable)
    <37>   DW_AT_name        : (indexed string: 0xc): v2
    <38>   DW_AT_type        : <0x68>
    <3c>   DW_AT_external    : 1
    <3e>   DW_AT_linkage_name: (indexed string: 0xd): _ZN1a2v2E
...

So, we have DW_AT_linkage_name for both.

With a gdb patch like this:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 98cc1aa5b94..d2972d647e9 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -15894,6 +15894,11 @@ new_symbol (struct die_info *die, struct type *type,
struct dwarf2_cu *cu,

                  sym->set_loc_class_index (LOC_UNRESOLVED);
                }
+             else if (!die_is_declaration (die, cu) && linkagename != nullptr)
+               {
+                 sym->set_loc_class_index (LOC_UNRESOLVED);
+                 list_to_add = cu->list_in_scope;
+               }
              else if (!die_is_declaration (die, cu))
                {
                  /* Use the default LOC_OPTIMIZED_OUT class.  */
...
we get:
...
$1 = {x = 1, y = 2, z = 3}
$2 = {x = 1, y = 2, z = 3}
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #9)

> +             else if (!die_is_declaration (die, cu) && linkagename !=
> nullptr)
> +               {
> +                 sym->set_loc_class_index (LOC_UNRESOLVED);
> +                 list_to_add = cu->list_in_scope;
> +               }

Testing this patch revealed no regressions, but now I wonder whether I can
write a counter example.

Perhaps the logic is incorrect, and it's simply the case that since this is a
static var, there can be multiple instances, and we can't tell for which
instance the minimal symbol will end up in the exec.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/27886] static thread_local on aarch64 are broken in gdb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27886

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Counter example:
...
$ cat test.h
struct kk
{
  kk() = default;
  int x = 1, y = 2, z = 3;
  ~kk() {}
};

namespace a
{

  static thread_local kk v1;
}
$ cat test.c
#include "test.h" 

extern void foo (void);

int
main (void)
{
  foo ();

  return 0;
}
$ cat test-2.c
#include "test.h" 

void
foo (void)
{
  a::v1.x++;
  a::v1.y++;
  a::v1.z++;
}
...

With the patch, when stopping in the middle of foo, say after executing the x
increment, we have:
...
(gdb) p a::v1
$1 = {x = 1, y = 2, z = 3}
...
so we're printing the value of a::v1 from test.c, not from test-2.c.

So, nevermind, sorry for the noise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.