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

[Yao Qi <qiyaoltc at gmail dot com>]

On 17-11-16 14:40:18, Wei-min Pan wrote:
> 
> 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.
> 
> 

I finally understand what your patches does.  It is about finding TLS
variables from msymbol instead of full symbol.  It is nothing specific
to aarch64.  We've already had a test case gdb.threads/tls-nodebug.exp,
but it is about C, rather than C++.  Can you extend this test case for
a C++ TLS (which is mangled)?  I expect that GDB can't find the mangled
TLS without debug info on any architecture, and your patch fixes this
issue.

Even with your patch applied, there is still one fail in
gdb.threads/tls.exp,

-Cannot read `a_thread_local' without registers^M
-(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
+Cannot find thread-local storage for process 0, executable file /home/yao.qi/gnu/build/gdb/testsuite/outputs/gdb.threads/tls/tls:^M
+Cannot find thread-local variables on this target^M
+(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local

Looks GDB error messages in different code patch should be adjusted
as well.

-- 
Yao (齐尧)