This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu
- From: Wei-min Pan <weimin dot pan at oracle dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 16 Nov 2017 14:40:18 -0800
- Subject: Re: [PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu
- Authentication-results: sourceware.org; auth=none
- References: <1509669516-47946-1-git-send-email-weimin.pan@oracle.com> <868tf6twly.fsf@gmail.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.