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

[Weimin Pan <weimin.pan@oracle.com>]

On 11/21/2017 7:36 AM, Yao Qi wrote:
> 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.

If the test is built with no -g, my patch won't be able to find the C++ 
TLS either.  For example,

class foo {
  public:
   static __thread int total;
};

__thread int foo::total = 31;

Its mangled name is _ZN3foo5totalE and it's the only way to access the 
C++ TLS.

>
> 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

Please note that the failed "print" command, which operated on a C TLS, was
issued before the test program got executed. For arch other than 
aarch64, the
checking of SYMBOL_NEEDS_REGISTERS && target_has_registers was done 
early and
resulted in "without registers" error for program that hasn't started in
default_read_var_value().

But for aarch64, it didn't fail until the to_get_thread_local_address() call
which caused the "Cannot find thread-local storage" exception.

BTW, this was (1) in my original patch report.


Thanks.

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