From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 08353386F439 for ; Mon, 15 Jun 2020 21:42:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 08353386F439 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-293--iOXXaFCOKWKBm5xATOFGg-1; Mon, 15 Jun 2020 17:42:29 -0400 X-MC-Unique: -iOXXaFCOKWKBm5xATOFGg-1 Received: by mail-wr1-f71.google.com with SMTP id o1so7482129wrm.17 for ; Mon, 15 Jun 2020 14:42:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/qKji7YYvpb6ynUKyZsIlfvWE8dLGFm5YtI/mQelAoM=; b=Ld/7xzdbIiYArWEFikWro9T5qFX46bvQ85fcXJSe7md0ysXDTl1ll1gYAXoBPFO/H+ UrhjiMuflhS1cNZOkyG4rIU0VdlGZY5XKC/dOeGPxkOF/2seBBAvZR0rcHUvgVlVyhWc PTlCfNzBdnbRwgRIyv/3gZsJynYLoLh+4auWd8CI6dSpps8auaLSu/gIy9ggnGT5Haro rL9bMIpka+VWBoXLRjeerkOnMho7M9uFftZ3XSRMTY7n/P/TmKMg3DG4n57tV13NBFHC skQ3p49F2HT1/Xx6LijpdVhZITUHNsWa7N/w9cVWcyg44SQvPsIRMPH+LD4EF9QXCxBQ 5p0A== X-Gm-Message-State: AOAM53103agdyMc/BbifoxyeK5GssUN7ZysUuKAEKlFMfBS/yopl2u/X GXAc/c7syHFuocCk1l+n9iuwKEsK2e+IavTy50GcmnGPBHmhKc7Ga6yN8wtXKrEtw4MUbsmBgxT Ry1V1bA5A+Gg= X-Received: by 2002:a1c:254:: with SMTP id 81mr1233222wmc.93.1592257348387; Mon, 15 Jun 2020 14:42:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyYueWysZygDgPSzd4kEk0Qdl1lUiWPSLKqATQILjUQGShC4/4WDaJOs3JPHC02IlixSTvWNQ== X-Received: by 2002:a1c:254:: with SMTP id 81mr1233208wmc.93.1592257348053; Mon, 15 Jun 2020 14:42:28 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id y14sm1020344wma.25.2020.06.15.14.42.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 14:42:27 -0700 (PDT) Subject: Re: gdb show thread names To: Jonny Grant , Philippe Waroquiers , gdb@sourceware.org References: <030e3603-12ab-d3cb-afe7-2628acbc18e3@jguk.org> <5e3daadd5ee841b6f6d4ba4948849fa53ffe2107.camel@skynet.be> <9cbff50e-5268-98a9-7648-af53bacc1940@redhat.com> <53594350-729f-4098-3cc8-225e536045da@jguk.org> From: Pedro Alves Message-ID: Date: Mon, 15 Jun 2020 22:42:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <53594350-729f-4098-3cc8-225e536045da@jguk.org> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 21:42:33 -0000 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