[Bug exp/30271] New: Addresses of static thread_local fields are badly calculated sometimes

["michal.chojnowski at scylladb dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 30271
           Summary: Addresses of static thread_local fields are badly
                    calculated sometimes
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: exp
          Assignee: unassigned at sourceware dot org
          Reporter: michal.chojnowski at scylladb dot com
  Target Milestone: ---

Created attachment 14779
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14779&action=edit
A patch adding thread_local field handling to value_static_field (possibly in a
wrong manner).

Bottom line:

value_static_field() isn't aware of thread_local fields. It just uses the
address returned by lookup_minimum_symbol() as-is, and for thread_local
variables that's wrong, because in their case the returned value is a TLS
section offset, not the address.

Context:

After we upgraded gdb from 12.1 to 13.1, we noticed that some of our gdb
scripts stopped working because gdb started to evaluate `&a::b` (where `a::b`
is an important `static thread_local` C++ variable) to the TLS offset of `a::b`
instead of its runtime address.
We bisected the problem to commit 3d20b8d99a54382e6e1a6c433e71e0775c6856c6
(`Enable the new DWARF indexer`). When observing the execution of GDB before
and after this patch, we learned that before it the variable would be
successfully looked up via `lookup_symbol_via_quick_fns()`, but after it
`lookup_symbol_via_quick_fns()` doesn't succeed in looking the variable up
(could this be a problem of its own?) and GDB progresses to
`evaluate_expression` -> `value_aggregate_elt` -> `value_static_field` ->
`lookup_minimal_symbol`, and this secondary code path gives the wrong result
because it just can't handle thread_local variables.

I have attached a patch (which I based on some code found in findvars.c) which
fixes our problem. (But I'm clueless about GDB internals, so I can't say
anything about the quality of this patch other than that it solves our
particular case.)

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