* Printing thread_local a.k.a. __thread variables
@ 2018-02-12 13:30 Dmitry Antipov
2018-02-12 14:02 ` Yao Qi
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Antipov @ 2018-02-12 13:30 UTC (permalink / raw)
To: GDB Development
[-- Attachment #1: Type: text/plain, Size: 214 bytes --]
I just tried the recent git snapshot (on x86 GNU/Linux) and always seeing
100 for 'tlocal' variable. Compiled wit GCC 7.3, -O0 -g3, regardless of
-gdwarf-4 default or -gdwarf-5. Am I doing wrong something?
Dmitry
[-- Attachment #2: t-thread.cc --]
[-- Type: text/x-c++src, Size: 1194 bytes --]
#include <vector>
#include <chrono>
#include <thread>
#include <string>
#include <cstdio>
#include <cstring>
#include <cstdlib>
int depth;
thread_local int tlocal = 100;
void
bp1 (int t, int level, int n)
{
auto r = std::rand () % (t + level + n);
std::this_thread::sleep_for (std::chrono::milliseconds (r));
printf ("bp1 in thread %d: %d\n", t, tlocal);
}
void
bp2 (int t, int level, int n)
{
auto r = std::rand () % (t + level + n);
std::this_thread::sleep_for (std::chrono::milliseconds (r));
printf ("bp2 in thread %d: %d\n", t, tlocal);
}
void
sleeper (int t, int level, int n)
{
int loop = 0;
if (++level < depth)
sleeper (t, level, n);
else
while (true)
{
if (++loop % 2)
bp1 (t, level, n);
else
bp2 (t, level, n);
tlocal += t + 1;
}
}
int
main (int argc, char *argv[])
{
auto max = argc > 1 ? std::atoi (argv[1]) : 8;
depth = argc > 2 ? std::atoi (argv[2]) : 16;
std::vector<std::thread *> T;
for (auto i = 0; i < max; i++)
{
auto t = new std::thread (sleeper, i, 0, 1000);
pthread_setname_np (t->native_handle (), "worker");
T.push_back (t);
}
for (auto &t: T)
t->join ();
return 0;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing thread_local a.k.a. __thread variables
2018-02-12 13:30 Printing thread_local a.k.a. __thread variables Dmitry Antipov
@ 2018-02-12 14:02 ` Yao Qi
2018-02-12 14:15 ` Dmitry Antipov
0 siblings, 1 reply; 6+ messages in thread
From: Yao Qi @ 2018-02-12 14:02 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: GDB Development
On Mon, Feb 12, 2018 at 1:29 PM, Dmitry Antipov <dantipov@nvidia.com> wrote:
> I just tried the recent git snapshot (on x86 GNU/Linux) and always seeing
> 100 for 'tlocal' variable. Compiled wit GCC 7.3, -O0 -g3, regardless of
> -gdwarf-4 default or -gdwarf-5. Am I doing wrong something?
>
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.
Thread 1 "2.exe" received signal SIGINT, Interrupt.
0x00007ffff7bc565b in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) p tlocal
$1 = 100
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff6fc6700 (LWP 29726))]
#0 0x00007ffff7bcbb9d in nanosleep () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) p tlocal
$2 = 104
(gdb) thread 4
[Switching to thread 4 (Thread 0x7ffff5fc4700 (LWP 29728))]
#0 0x00007ffff7bcbb9d in nanosleep () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) p tlocal
$4 = 112
(gdb) thread apply all print tlocal
Thread 9 (Thread 0x7ffff37bf700 (LWP 29733)):
$5 = 148
Thread 8 (Thread 0x7ffff3fc0700 (LWP 29732)):
$6 = 121
Thread 7 (Thread 0x7ffff47c1700 (LWP 29731)):
$7 = 124
Thread 6 (Thread 0x7ffff4fc2700 (LWP 29730)):
$8 = 110
Thread 5 (Thread 0x7ffff57c3700 (LWP 29729)):
$9 = 112
Thread 4 (Thread 0x7ffff5fc4700 (LWP 29728)):
$10 = 112
Thread 3 (Thread 0x7ffff67c5700 (LWP 29727)):
$11 = 108
Thread 2 (Thread 0x7ffff6fc6700 (LWP 29726)):
$12 = 104
Thread 1 (Thread 0x7ffff7fca780 (LWP 29722)):
$13 = 100
--
Yao (齐尧)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing thread_local a.k.a. __thread variables
2018-02-12 14:02 ` Yao Qi
@ 2018-02-12 14:15 ` Dmitry Antipov
2018-02-12 14:54 ` Yao Qi
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Antipov @ 2018-02-12 14:15 UTC (permalink / raw)
To: Yao Qi; +Cc: GDB Development
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:
(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
(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?
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing thread_local a.k.a. __thread variables
2018-02-12 14:15 ` Dmitry Antipov
@ 2018-02-12 14:54 ` Yao Qi
2018-02-13 7:55 ` Dmitry Antipov
0 siblings, 1 reply; 6+ messages in thread
From: Yao Qi @ 2018-02-12 14:54 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: GDB Development
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 (齐尧)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing thread_local a.k.a. __thread variables
2018-02-12 14:54 ` Yao Qi
@ 2018-02-13 7:55 ` Dmitry Antipov
2018-02-13 9:19 ` Yao Qi
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Antipov @ 2018-02-13 7:55 UTC (permalink / raw)
To: Yao Qi; +Cc: GDB Development
On 02/12/2018 05:54 PM, Yao Qi wrote:
> ... 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'?
It seems that 'qGetTLSAddr' fails every time for any thread in question:
(gdb) info threads
Id Target Id Frame
* 1 Thread 19378.19378 "t-thread" 0x00007f62ae10b89d in pthread_join () from target:/lib64/libpthread.so.0
2 Thread 19378.19379 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
3 Thread 19378.19380 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
4 Thread 19378.19381 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
5 Thread 19378.19382 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
6 Thread 19378.19383 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
7 Thread 19378.19384 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
8 Thread 19378.19385 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
9 Thread 19378.19386 "worker" 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
(gdb) print tlocal
Cannot find thread-local storage for Thread 19378.19378, executable file target:/home/dantipov/tmp/t-thread:
Remote target failed to process qGetTLSAddr request
(gdb) thread 2
[Switching to thread 2 (Thread 19378.19379)]
#0 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
(gdb) print tlocal
Cannot find thread-local storage for Thread 19378.19379, executable file target:/home/dantipov/tmp/t-thread:
Remote target failed to process qGetTLSAddr request
(gdb) thread 3
[Switching to thread 3 (Thread 19378.19380)]
#0 0x00007f62ae11499d in nanosleep () from target:/lib64/libpthread.so.0
(gdb) print tlocal
Cannot find thread-local storage for Thread 19378.19380, executable file target:/home/dantipov/tmp/t-thread:
Remote target failed to process qGetTLSAddr request
gdbserver output is:
...
getpkt ("qGetTLSAddr:p4bb2.4bb2,0,7f62aedff330"); [no ack sent]
putpkt ("$E01#a6"); [noack mode]
...
getpkt ("qGetTLSAddr:p4bb2.4bb3,0,7f62aedff330"); [no ack sent]
putpkt ("$E01#a6"); [noack mode]
...
getpkt ("qGetTLSAddr:p4bb2.4bb4,0,7f62aedff330"); [no ack sent]
putpkt ("$E01#a6"); [noack mode]
...
As for the local debugging, the same GDB binary on the same system works as expected:
(gdb) i thr
Id Target Id Frame
* 1 Thread 0x7f62aedd2740 (LWP 19378) "t-thread" 0x00007f62ae10b89d in pthread_join () from /lib64/libpthread.so.0
2 Thread 0x7f62add2d700 (LWP 19379) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
3 Thread 0x7f62ad52c700 (LWP 19380) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
4 Thread 0x7f62acd2b700 (LWP 19381) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
5 Thread 0x7f62ac52a700 (LWP 19382) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
6 Thread 0x7f62abd29700 (LWP 19383) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
7 Thread 0x7f62ab528700 (LWP 19384) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
8 Thread 0x7f62aad27700 (LWP 19385) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
9 Thread 0x7f62aa526700 (LWP 19386) "worker" 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
(gdb) print tlocal
$1 = 100
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f62add2d700 (LWP 19379))]
#0 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
(gdb) print tlocal
$2 = 653
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f62ad52c700 (LWP 19380))]
#0 0x00007f62ae11499d in nanosleep () from /lib64/libpthread.so.0
(gdb) print tlocal
$3 = 1220
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing thread_local a.k.a. __thread variables
2018-02-13 7:55 ` Dmitry Antipov
@ 2018-02-13 9:19 ` Yao Qi
0 siblings, 0 replies; 6+ messages in thread
From: Yao Qi @ 2018-02-13 9:19 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: GDB Development
On Tue, Feb 13, 2018 at 7:55 AM, Dmitry Antipov <dantipov@nvidia.com> wrote:
> On 02/12/2018 05:54 PM, Yao Qi wrote:
>
>> ... 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'?
>
>
> It seems that 'qGetTLSAddr' fails every time for any thread in question:
>
It works for me with GDBserver. You can debug gdbserver to see why
qGetTLSAddr is not handled properly. The related function is
thread-db.c:thread_db_get_tls_address.
--
Yao (齐尧)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-02-13 9:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-12 13:30 Printing thread_local a.k.a. __thread variables Dmitry Antipov
2018-02-12 14:02 ` Yao Qi
2018-02-12 14:15 ` Dmitry Antipov
2018-02-12 14:54 ` Yao Qi
2018-02-13 7:55 ` Dmitry Antipov
2018-02-13 9:19 ` Yao Qi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox