Re: Printing thread_local a.k.a. __thread variables

[Yao Qi <qiyaoltc@gmail.com>]

On Mon, Feb 12, 2018 at 2:15 PM, Dmitry Antipov <dantipov@nvidia.com> wrote:
> On 02/12/2018 05:02 PM, Yao Qi wrote:
>
>> Because you are in thread 1, main thread, in which tlocal is not changed.
>> If you switch to other threads, you'll see the right value of tlocal.
>
> Argh. But this seems doesn't work for extended-remote target:
>

What is "this"?  Can you be more explicit and precise? ....

> (gdb) thread apply all print tlocal
>
> Thread 9 (Thread 10463.10471):
> Cannot find thread-local storage for Thread 10463.10471, executable file
> target:/tmp/t-thread:
> Remote target failed to process qGetTLSAddr request

... is it broken in every threads in "thread apply all" or just in some
threads?  Can you reproduce it every time or it is intermittent?
If you manually switch threads via command "thread N", can
you examine 'tlocal'?

I remember that there may be a race that GDB is already aware of a
thread, but libthread_db still isn't.

>
> (gdbserver side with '--remote-debug' agrees with the above):
>
> getpkt ("qGetTLSAddr:p28df.28e7,0,7f963e8a7330");  [no ack sent]
> putpkt ("$E01#a6"); [noack mode]
>
> Is my gdbserver is mis(configured|compiled) and do something wrong with
> libthread_db?
>

If GDBserver can get TLS address for some threads, but failed for others,
GDBserver must be configured/compiled correctly.

-- 
Yao (齐尧)