aarch64: Make "info address" resolve TLS variables
authorWeimin Pan <weimin.pan@oracle.com>
Fri, 3 Nov 2017 00:38:36 +0000 (18:38 -0600)
committerSimon Marchi <simon.marchi@polymtl.ca>
Sat, 24 Mar 2018 02:57:46 +0000 (22:57 -0400)
commitbce02d8884d6baa72c537d0d7c59f924cb290799
tree81c208f2daa6d456ba31a63a938101db5313a578
parent9a96cf38344355c529bfb47251a01ad679d75459
aarch64: Make "info address" resolve TLS variables

TLS variables can't be resolved on aarch64-linux-gnu

Running the test case with upstream gdb shows two failures:

(1) Receiving different error messages when printing TLS variable before
    program runs - because the ARM compiler does not emit dwarf attribute
    DW_AT_location for TLS, the result is expected and the baseline may
    need to be changed for aarch64.

(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).

Function info_address_command() handles the "info address" command and
calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in
mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is
that function lookup_minimal_symbol_and_objfile() only looked up an
objfile's minsym ordinary hash table, not its demangled hash table, which
was the reason why the C++ name was not found.

The fix is to call lookup_minimal_symbol(), which already looks up entries
in both minsym's hash tables, to find names when traversing the object file
list in lookup_minimal_symbol_and_objfile().

Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions.
gdb/ChangeLog
gdb/minsyms.c
gdb/minsyms.h