* gdb show thread names @ 2020-06-13 0:16 Jonny Grant 2020-06-13 12:47 ` Philippe Waroquiers 2020-06-15 11:42 ` Kamil Rytarowski 0 siblings, 2 replies; 12+ messages in thread From: Jonny Grant @ 2020-06-13 0:16 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-13 0:16 gdb show thread names Jonny Grant @ 2020-06-13 12:47 ` Philippe Waroquiers 2020-06-13 22:22 ` Jonny Grant 2020-06-15 11:42 ` Kamil Rytarowski 1 sibling, 1 reply; 12+ messages in thread From: Philippe Waroquiers @ 2020-06-13 12:47 UTC (permalink / raw) To: Jonny Grant, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 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 0 siblings, 2 replies; 12+ messages in thread From: Jonny Grant @ 2020-06-13 22:22 UTC (permalink / raw) To: Philippe Waroquiers, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-13 22:22 ` Jonny Grant @ 2020-06-14 14:22 ` Philippe Waroquiers 2020-06-15 15:51 ` Pedro Alves 1 sibling, 0 replies; 12+ messages in thread From: Philippe Waroquiers @ 2020-06-14 14:22 UTC (permalink / raw) To: Jonny Grant, gdb 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 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 1 sibling, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-15 15:51 UTC (permalink / raw) To: Jonny Grant, Philippe Waroquiers, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-15 15:51 ` Pedro Alves @ 2020-06-15 16:21 ` Philippe Waroquiers 2020-06-15 20:53 ` Jonny Grant 0 siblings, 1 reply; 12+ messages in thread From: Philippe Waroquiers @ 2020-06-15 16:21 UTC (permalink / raw) To: Pedro Alves, Jonny Grant, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-15 16:21 ` Philippe Waroquiers @ 2020-06-15 20:53 ` Jonny Grant 2020-06-15 21:12 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Jonny Grant @ 2020-06-15 20:53 UTC (permalink / raw) To: Philippe Waroquiers, Pedro Alves, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-15 20:53 ` Jonny Grant @ 2020-06-15 21:12 ` Pedro Alves 2020-06-15 21:28 ` Jonny Grant 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-15 21:12 UTC (permalink / raw) To: Jonny Grant, Philippe Waroquiers, gdb 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-15 21:12 ` Pedro Alves @ 2020-06-15 21:28 ` Jonny Grant 2020-06-15 21:42 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Jonny Grant @ 2020-06-15 21:28 UTC (permalink / raw) To: Pedro Alves, Philippe Waroquiers, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-15 21:28 ` Jonny Grant @ 2020-06-15 21:42 ` Pedro Alves 0 siblings, 0 replies; 12+ messages in thread From: Pedro Alves @ 2020-06-15 21:42 UTC (permalink / raw) To: Jonny Grant, Philippe Waroquiers, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-13 0:16 gdb show thread names Jonny Grant 2020-06-13 12:47 ` Philippe Waroquiers @ 2020-06-15 11:42 ` Kamil Rytarowski 2020-06-15 15:25 ` Jonny Grant 1 sibling, 1 reply; 12+ messages in thread From: Kamil Rytarowski @ 2020-06-15 11:42 UTC (permalink / raw) To: Jonny Grant, gdb [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: gdb show thread names 2020-06-15 11:42 ` Kamil Rytarowski @ 2020-06-15 15:25 ` Jonny Grant 0 siblings, 0 replies; 12+ messages in thread From: Jonny Grant @ 2020-06-15 15:25 UTC (permalink / raw) To: Kamil Rytarowski, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-06-15 21:42 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-13 0:16 gdb show thread names 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 2020-06-15 21:42 ` Pedro Alves 2020-06-15 11:42 ` Kamil Rytarowski 2020-06-15 15:25 ` Jonny Grant
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).