Re: gdb show thread names

[Pedro Alves <palves@redhat.com>]

On 6/13/20 11:22 PM, Jonny Grant wrote:
> 
> 
> On 13/06/2020 13:47, Philippe Waroquiers wrote:
>> One year ago, I started a patch to add Ada task names and thread names.
>> At the end, the patch for Ada task name went in, but for the thread
>> names, there were still some work to do e.g. it was unclear how to
>> properly give the thread name in some cases and/or 
>> have a consistent presentation of the thread name.
>>
>> The (partial) patch was giving a behaviour so that we e.g. get:
>>       [New Thread 0x7ffff701b700 (LWP 13891) "sleepers"]
>>       [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13890) "sleepers")]
>>     instead of:
>>       [New Thread 0x7ffff701b700 (LWP 13918)]
>>       [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13917))]
>>
>> Philippe
>>
>> On Sat, 2020-06-13 at 01:16 +0100, Jonny Grant wrote:
>>> Hello
>>> Just wondering if gdb could show the thread names as they are created and deleted?
>>>
>>>
>>> [Thread 0x7fff695e9700 (LWP 3580240) exited]
>>> [New Thread 0x7fff98ff9700 (LWP 3580609)]
>>>
>>> $ cat /proc/3580609/comm
>>> ThreadPoolForeg
>>>
>>> Could be a race condition, if GDB showed the name, before it was renamed by the application, but still pretty useful to see the names.
>>>
>>> If I break, and type "info thread" I can see those still created.
>>>
>>> Jonny
>>
> 
> Hi Philippe
> 
> That looks useful. Is "sleepers" the entrypoint symbol name?
> 
> I can see it is tricky because a thread may not have been named by something like pthread_setname_np() if /proc/3580609/comm is read immediately by gdb before the name could be set.

Yes, I think that's the main issue -- we get a thread creation event before the
thread is renamed, so that means that the name GDB would print would be misleading.

So e.g., if we tweak gdb to print the thread name like this:

diff --git c/gdb/thread.c w/gdb/thread.c
index dfdb6b339bf..e04dce0ec5b 100644
--- c/gdb/thread.c
+++ w/gdb/thread.c
@@ -303,7 +303,10 @@ add_thread_with_info (process_stratum_target *targ, ptid_t ptid,
   result->priv.reset (priv);
 
   if (print_thread_events)
-    printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid).c_str ());
+    {
+      printf_unfiltered (_("[New %s \"%s\"]\n"), target_pid_to_str (ptid).c_str (),
+                        target_thread_name (result));
+    }


Then we get, on a GDB testcase that has threads immediately set their names
first thing:

(gdb) b all_threads_ready 
Breakpoint 1 at 0x4007f5: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/names.c, line 51.
(gdb) r
Starting program: /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/names/names 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff74b8700 (LWP 24171) "main"]
[New Thread 0x7ffff6cb7700 (LWP 24172) "main"]
[New Thread 0x7ffff64b6700 (LWP 24173) "main"]

Thread 1 "main" hit Breakpoint 1, all_threads_ready () at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/names.c:51
51      }
(gdb) info threads 
  Id   Target Id                                  Frame 
* 1    Thread 0x7ffff7fb5740 (LWP 24170) "main"   all_threads_ready () at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/names.c:51
  2    Thread 0x7ffff74b8700 (LWP 24171) "carrot" 0x00007ffff7bc89aa in futex_wait (private=0, expected=4, futex_word=0x7fffffffd604) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
  3    Thread 0x7ffff6cb7700 (LWP 24172) "potato" 0x00007ffff7bc89aa in futex_wait (private=0, expected=4, futex_word=0x7fffffffd604) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
  4    Thread 0x7ffff64b6700 (LWP 24173) "celery" 0x00007ffff7bc89aa in futex_wait (private=0, expected=4, futex_word=0x7fffffffd604) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
(gdb) 

I.e., printing the thread name when the thread is created
looks more confusing than helpful to me.

Thanks,
Pedro Alves