Re: gdb show thread names

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
>