From: Jonny Grant <jg@jguk.org>
To: Pedro Alves <palves@redhat.com>,
Philippe Waroquiers <philippe.waroquiers@skynet.be>,
gdb@sourceware.org
Subject: Re: gdb show thread names
Date: Mon, 15 Jun 2020 22:28:41 +0100 [thread overview]
Message-ID: <53594350-729f-4098-3cc8-225e536045da@jguk.org> (raw)
In-Reply-To: <b1905b50-47f9-18bc-b02f-d6f0646589b5@redhat.com>
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
next prev parent reply other threads:[~2020-06-15 21:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-13 0:16 Jonny Grant
2020-06-13 12:47 ` Philippe Waroquiers
2020-06-13 22:22 ` Jonny Grant
2020-06-14 14:22 ` Philippe Waroquiers
2020-06-15 15:51 ` Pedro Alves
2020-06-15 16:21 ` Philippe Waroquiers
2020-06-15 20:53 ` Jonny Grant
2020-06-15 21:12 ` Pedro Alves
2020-06-15 21:28 ` Jonny Grant [this message]
2020-06-15 21:42 ` Pedro Alves
2020-06-15 11:42 ` Kamil Rytarowski
2020-06-15 15:25 ` Jonny Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53594350-729f-4098-3cc8-225e536045da@jguk.org \
--to=jg@jguk.org \
--cc=gdb@sourceware.org \
--cc=palves@redhat.com \
--cc=philippe.waroquiers@skynet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).