Re: [PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu

[Wei-min Pan <weimin dot pan at oracle dot com>]

On 11/16/2017 1:13 AM, Yao Qi wrote:
> Weimin Pan <weimin.pan@oracle.com> writes:
>
> > (2) Using "info address" command on C++ static TLS object resulted in
> >      "symbol unresolved" error - below is a snippet from the test case:
> >
> > class K {
> >   public:
> >    static __thread int another_thread_local;
> > };
> >
> > __thread int K::another_thread_local;
> >
> > (gdb) info address K::another_thread_local
> > Symbol "K::another_thread_local" is unresolved.
> >
> > This patch contains fix for (2).
> Why do we need to fix (2)?  It is a result of (1).  If DW_AT_location is
> generated,
>
> info address K::another_thread_local^M
> Symbol "K::another_thread_local" is a thread-local variable at offset 0x4 in the thread-local storage for `gdb/testsuite/outputs/gdb.threads/tls/tls'.
>
> without DW_AT_location, how does GDB tell where this variable is?  The
> right fix to me is to fix GCC bug PR 83010, and xfail these tests here
> for aarch64.

If a TLS does not have a DW_AT_location, it can still be found in the
.tbss section (with flag SEC_THREAD_LOCAL being set) which GLIBC uses
for TLS storage and that's what gdb function info_address_command()
tries to find by calling lookup_minimal_symbol_and_objfile().

Problem is, as described in the patch, lookup_minimal_symbol_and_objfile()
only looked up an objfile's minsym ordinary hash table, not its demangled
hash table, and resulted in not finding the C++ name.