From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id F02EF3887013 for ; Mon, 15 Jun 2020 15:51:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F02EF3887013 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-214-scn4OSteMuC5UCzG_T99uQ-1; Mon, 15 Jun 2020 11:51:57 -0400 X-MC-Unique: scn4OSteMuC5UCzG_T99uQ-1 Received: by mail-wr1-f69.google.com with SMTP id x15so5837168wru.21 for ; Mon, 15 Jun 2020 08:51:56 -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=i0YDqRGhyUSL0gXwFq1FsXxj7qysfRfM12Q4Q0kYle0=; b=P8Du7Ph+ccen86CCtyWLN52tFuScsN8tefpVhxDJAKdf9R70QyCQlBN+R7YDds4rBq DfX7cAFbavEfxZCi9S2KU7RNBMXyi9LRg8bMl5ywu2TvrmVWh9plwkwz6RAFbgzEK553 Kr9Kp1ceMFBUfuJuLrIGiK8gKaydmMxpfNEIhbyNC1yrbypalz/BEUwEoiEQd+VaqSei 2fFBpNg0gP1trp1JDGQF9uFSJ0vgrHQxSg8mpPpTJhluBezwVyW6cs8Aae1Fkz/uQskJ pgJvQzGmtxcFZ/xmZJRK+jQLx+l3bscP4pSZXYGNlfMYA1jzFh9qUwCgSvR6BwxB2aTb rXxA== X-Gm-Message-State: AOAM5313HZ/i/CVH9Xnv/BG+xauqhY443Yj+/h1ZYO1pqOuUrCWLbSRH moJa4vs8ttaXaOsGZNeNPd7C6nQ0hNo9hPLLObZyoYhRm52Iiz5g7wjvmqct0csE4Z1vPjDVrBi XIYdvKMWj0BY= X-Received: by 2002:adf:f68d:: with SMTP id v13mr27760134wrp.291.1592236315682; Mon, 15 Jun 2020 08:51:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkHylFtwnOV7tju5+idy5CNPl9JRccTT5w+37udUvZAbPAHswm6MGXgzEjKd8XjhaDcGzq5Q== X-Received: by 2002:adf:f68d:: with SMTP id v13mr27760123wrp.291.1592236315475; Mon, 15 Jun 2020 08:51:55 -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 c6sm24363520wma.15.2020.06.15.08.51.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 08:51:54 -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> From: Pedro Alves Message-ID: <9cbff50e-5268-98a9-7648-af53bacc1940@redhat.com> Date: Mon, 15 Jun 2020 16:51:54 +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: 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=-8.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, 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 15:52:00 -0000 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