gdb show thread names

gdb show thread names

[Jonny Grant]

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

Re: gdb show thread names

[Philippe Waroquiers]

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

Re: gdb show thread names

[Jonny Grant]

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.

Jonny

Re: gdb show thread names

[Philippe Waroquiers]

On Sat, 2020-06-13 at 23:22 +0100, Jonny Grant wrote:
> 
> That looks useful. Is "sleepers" the entrypoint symbol name?
It is the same info shown in the 'info thread' output.

Re: gdb show thread names

[Kamil Rytarowski]

[-- Attachment #1.1: Type: text/plain, Size: 807 bytes --]

On 13.06.2020 02:16, Jonny Grant wrote:
> Hello
> Just wondering if gdb could show the thread names as they are created and deleted?
> 

As created generally no, as it gets a meaningful name usually after
creation from a dedicated syscall.

If there is a legitimate use-case, I can implement reporting thread
rename for NetBSD and report in GDB. But as we would report thread
renames, what about other events?

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: gdb show thread names

[Jonny Grant]

On 15/06/2020 12:42, Kamil Rytarowski wrote:
> On 13.06.2020 02:16, Jonny Grant wrote:
>> Hello
>> Just wondering if gdb could show the thread names as they are created and deleted?
>>
> 
> As created generally no, as it gets a meaningful name usually after
> creation from a dedicated syscall.
> 
> If there is a legitimate use-case, I can implement reporting thread
> rename for NetBSD and report in GDB. But as we would report thread
> renames, what about other events?

Not sure about other events, I only saw this useful use case.

Thank you
Jonny

Re: gdb show thread names

[Pedro Alves]

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

Re: gdb show thread names

[Philippe Waroquiers]

On Mon, 2020-06-15 at 16:51 +0100, Pedro Alves wrote:
> 
> 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.
Yes, that is confusing.

And for the following events, when I tried, the patch was far to be ready 
e.g. for the exit events, it gives (for the above):
  (gdb) c
  Continuing.
  [Thread 0x7ffff743d700 (LWP 22783) exited]
  [Thread 0x7ffff7c3e700 (LWP 22782) exited]
  [Thread 0x7ffff7c3f740 (LWP 22778) "main" exited]

So, unclear why there is no carrot, potato or celery in the 2 exited threads
but "main" is present.
(and sometimes there is no names in any exited event).

So, when I looked at it, it needed quite some more work ...

Philippe

Re: gdb show thread names

[Jonny Grant]

On 15/06/2020 17:21, Philippe Waroquiers wrote:
> On Mon, 2020-06-15 at 16:51 +0100, Pedro Alves wrote:
>>
>> 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.
> Yes, that is confusing.
> 
> And for the following events, when I tried, the patch was far to be ready 
> e.g. for the exit events, it gives (for the above):
>   (gdb) c
>   Continuing.
>   [Thread 0x7ffff743d700 (LWP 22783) exited]
>   [Thread 0x7ffff7c3e700 (LWP 22782) exited]
>   [Thread 0x7ffff7c3f740 (LWP 22778) "main" exited]
> 
> So, unclear why there is no carrot, potato or celery in the 2 exited threads
> but "main" is present.
> (and sometimes there is no names in any exited event).
> 
> So, when I looked at it, it needed quite some more work ...
> 
> Philippe
> 

Hi, Maybe it is more complicated than it is worth after all.
Although, I did think new threads inherited the process executable name, rather than the main() symbol.

It's easy enough for me to press ^C and then type "info threads" so maybe it is fine as it is.
Would start to get awkward if GDB needs to interrupt and poll the proc "comm" file for each LWP etc

Regards, Jonny

Re: gdb show thread names

[Pedro Alves]

On 6/15/20 9:53 PM, Jonny Grant wrote:
> 
> 
> On 15/06/2020 17:21, Philippe Waroquiers wrote:
>> On Mon, 2020-06-15 at 16:51 +0100, Pedro Alves wrote:
>>>
>>> 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.
>> Yes, that is confusing.
>>
>> And for the following events, when I tried, the patch was far to be ready 
>> e.g. for the exit events, it gives (for the above):
>>   (gdb) c
>>   Continuing.
>>   [Thread 0x7ffff743d700 (LWP 22783) exited]
>>   [Thread 0x7ffff7c3e700 (LWP 22782) exited]
>>   [Thread 0x7ffff7c3f740 (LWP 22778) "main" exited]
>>
>> So, unclear why there is no carrot, potato or celery in the 2 exited threads
>> but "main" is present.
>> (and sometimes there is no names in any exited event).
>>
>> So, when I looked at it, it needed quite some more work ...
>>
>> Philippe
>>
> 
> Hi, Maybe it is more complicated than it is worth after all.
> Although, I did think new threads inherited the process executable name, rather than the main() symbol.

It's not the main() symbol, it's the name of the parent thread.
The testcase does:

  pthread_setname_np (pthread_self (), "main");

on the main thread before spawning the other threads.

So a child thread of "carrot" would be called "carrot" too by
default, until it changed its name.

If we removed that pthread_setname_np call on the main thread, then
the main thread's name would default to the process executable name
indeed.


If we included the thread id in these notifications instead, I think it
would be quite useful.  Like, we could have:

 [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) created]
 [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited]

Like we have:

 [Inferior 1 (process 13980) exited normally]

Thanks,
Pedro Alves

> 
> It's easy enough for me to press ^C and then type "info threads" so maybe it is fine as it is.
> Would start to get awkward if GDB needs to interrupt and poll the proc "comm" file for each LWP etc
> 
> Regards, Jonny
> 

Re: gdb show thread names

[Jonny Grant]

On 15/06/2020 22:12, Pedro Alves wrote:
> On 6/15/20 9:53 PM, Jonny Grant wrote:
>>
>>
>> On 15/06/2020 17:21, Philippe Waroquiers wrote:
>>> On Mon, 2020-06-15 at 16:51 +0100, Pedro Alves wrote:
>>>>
>>>> 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.
>>> Yes, that is confusing.
>>>
>>> And for the following events, when I tried, the patch was far to be ready 
>>> e.g. for the exit events, it gives (for the above):
>>>   (gdb) c
>>>   Continuing.
>>>   [Thread 0x7ffff743d700 (LWP 22783) exited]
>>>   [Thread 0x7ffff7c3e700 (LWP 22782) exited]
>>>   [Thread 0x7ffff7c3f740 (LWP 22778) "main" exited]
>>>
>>> So, unclear why there is no carrot, potato or celery in the 2 exited threads
>>> but "main" is present.
>>> (and sometimes there is no names in any exited event).
>>>
>>> So, when I looked at it, it needed quite some more work ...
>>>
>>> Philippe
>>>
>>
>> Hi, Maybe it is more complicated than it is worth after all.
>> Although, I did think new threads inherited the process executable name, rather than the main() symbol.
> 
> It's not the main() symbol, it's the name of the parent thread.
> The testcase does:
> 
>   pthread_setname_np (pthread_self (), "main");
> 
> on the main thread before spawning the other threads.
> 
> So a child thread of "carrot" would be called "carrot" too by
> default, until it changed its name.
> 
> If we removed that pthread_setname_np call on the main thread, then
> the main thread's name would default to the process executable name
> indeed.
> 
> 
> If we included the thread id in these notifications instead, I think it
> would be quite useful.  Like, we could have:
> 
>  [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) created]
>  [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited]


I'm just looking at my original email, I saw present behaviour is :-

[Thread 0x7fff695e9700 (LWP 3580240) exited]
[New Thread 0x7fff98ff9700 (LWP 3580609)]

May I ask which do you refer to as the 'thread id'?
I know on the Linux kernel there is gettid syscall, but they don't correspond to the pthread_self() handle.

Jonny

Re: gdb show thread names

[Pedro Alves]

On 6/15/20 10:28 PM, Jonny Grant wrote:
> 
> 
> On 15/06/2020 22:12, Pedro Alves wrote:
>> On 6/15/20 9:53 PM, Jonny Grant wrote:
>>>
>>>
>>> On 15/06/2020 17:21, Philippe Waroquiers wrote:
>>>> On Mon, 2020-06-15 at 16:51 +0100, Pedro Alves wrote:
>>>>>
>>>>> 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.
>>>> Yes, that is confusing.
>>>>
>>>> And for the following events, when I tried, the patch was far to be ready 
>>>> e.g. for the exit events, it gives (for the above):
>>>>   (gdb) c
>>>>   Continuing.
>>>>   [Thread 0x7ffff743d700 (LWP 22783) exited]
>>>>   [Thread 0x7ffff7c3e700 (LWP 22782) exited]
>>>>   [Thread 0x7ffff7c3f740 (LWP 22778) "main" exited]
>>>>
>>>> So, unclear why there is no carrot, potato or celery in the 2 exited threads
>>>> but "main" is present.
>>>> (and sometimes there is no names in any exited event).
>>>>
>>>> So, when I looked at it, it needed quite some more work ...
>>>>
>>>> Philippe
>>>>
>>>
>>> Hi, Maybe it is more complicated than it is worth after all.
>>> Although, I did think new threads inherited the process executable name, rather than the main() symbol.
>>
>> It's not the main() symbol, it's the name of the parent thread.
>> The testcase does:
>>
>>   pthread_setname_np (pthread_self (), "main");
>>
>> on the main thread before spawning the other threads.
>>
>> So a child thread of "carrot" would be called "carrot" too by
>> default, until it changed its name.
>>
>> If we removed that pthread_setname_np call on the main thread, then
>> the main thread's name would default to the process executable name
>> indeed.
>>
>>
>> If we included the thread id in these notifications instead, I think it
>> would be quite useful.  Like, we could have:
>>
>>  [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) created]
>>  [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited]
> 
> 
> I'm just looking at my original email, I saw present behaviour is :-
> 
> [Thread 0x7fff695e9700 (LWP 3580240) exited]
> [New Thread 0x7fff98ff9700 (LWP 3580609)]
> 
> May I ask which do you refer to as the 'thread id'?
> I know on the Linux kernel there is gettid syscall, but they don't correspond to the pthread_self() handle.

The "Id" reported in the first column of "info threads".

The "INF.THR" format is what GDB shows when you have multiple inferiors:

(gdb) add-inferior 
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) info threads 
  Id   Target Id                                 Frame 
* 1.1  Thread 0x7ffff7fb5740 (LWP 7275) "names"  all_threads_ready () at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/names.c:62
  1.2  Thread 0x7ffff74b8700 (LWP 7279) "carrot" 0x00007ffff7bc89aa in futex_wait (private=0, expected=4, futex_word=0x7fffffffd604) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
  1.3  Thread 0x7fffeffff700 (LWP 7281) "potato" 0x00007ffff7bc89aa in futex_wait (private=0, expected=4, futex_word=0x7fffffffd604) at ../sysdeps/unix/sysv/linux/futex-internal.h:61


So if we only have one inferior, it could be shown as:

  [Thread 2 (0x7ffff74b8700 (LWP 13984)) created]
  [Thread 2 (0x7ffff74b8700 (LWP 13984)) exited]
          ^       ^                ^
          |       |                |
          |       |                \-- kernel tid (gettid syscal)
          |       |
          |       \--- pthread_t (pthread_get_self() handle)
          |
           \-- gdb thread id ("info threads", "thread TID", etc.)

Thanks,
Pedro Alves