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: Yao Qi <qiyaoltc at gmail dot com>
- To: Weimin Pan <weimin dot pan at oracle dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 16 Nov 2017 09:13:13 +0000
- 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>
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.
--
Yao (齐尧)