From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by sourceware.org (Postfix) with ESMTPS id 4C166386F439 for ; Mon, 15 Jun 2020 21:28:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4C166386F439 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=jg@jguk.org Received: by mail-wr1-x444.google.com with SMTP id t18so18630746wru.6 for ; Mon, 15 Jun 2020 14:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=cTsr6D0m3LanPTuhc1npgvUsB3fB/NCqjjZvyZTWrjQ=; b=VjFWfr305rgRQbT7UhZhF+z2fY1qIiXO0CbC8oLnB9kMqI1LhqJo1XtwNYUcQOem7R Bkytcg11JmGH1X+LM6Ng7eDIDNY9iGcurjATDv7eSNEk8mH7/wzeS532ukdJC+QxgEcQ V1cRM9QU3B+Qcx+hUyWTHuTpKZdROFviA17pcwAiRMdSOtZQmO1LtAARe0+rT34iQDAz N+W5yRL4Pv5ENzG5lxEL9p9Ij/Rkc/1UZAhgpww/q3mFzZ5Ny+2vXgntPL94SNVAV5tE T0KvGyky0F5NG0L9R1A4kFYr8e9nQE56KNNZeUbVhTyvSzXmIssgMooR7c1YGSo2aphw D5ag== 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=cTsr6D0m3LanPTuhc1npgvUsB3fB/NCqjjZvyZTWrjQ=; b=ba46b0rtfFlLreEV90dlrOL/S/TBrzlm+azS6ZxexzT4bNAMWNiEtzXokh5gsH+bSD ZGrwODub2mhsBR2Pzd4IQ1l60weq5hBmabfPWaChTjuiiUnJGEDklzW9YLAbdQsJXHY8 iTzdnNfRFKvQ6j7C7NASh1k4viQm3+h5+CAtyNd0RkQi/giSxh8dl003Sn1ujuQuJjWn /Ad0KA8Zrdt9ii8rfx1fHaO+mh1/wn+sEODF+HSpzSgnEFoF+zOMwlN2mYz/anuIHiHO QLXdAz3pUMTQ2d5d3Exi/d1S2iPKrr13uqqVqTijDWjaL6t7T0DGCANZ0AjLl9I6+KbE 8QfA== X-Gm-Message-State: AOAM5322MTJUEM8TGRiwZ5pAQMj2Bx97HfV07uSXlFrPDGu4D7/q3gpa egaR6zD2vJbn+teKHj6Q21aYvsXSlFE= X-Google-Smtp-Source: ABdhPJzsbaHqW41snv8NZt5dyy6ldoJfM4adVj+8XEZIv2vwaac4WKOTepGuQkRSrjWA0v6Xxnt0+A== X-Received: by 2002:adf:ab09:: with SMTP id q9mr29935593wrc.79.1592256523957; Mon, 15 Jun 2020 14:28:43 -0700 (PDT) Received: from [192.168.0.12] (cpc87281-slou4-2-0-cust47.17-4.cable.virginm.net. [92.236.12.48]) by smtp.gmail.com with ESMTPSA id a3sm25121394wrp.91.2020.06.15.14.28.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 14:28:43 -0700 (PDT) Subject: Re: gdb show thread names To: Pedro Alves , Philippe Waroquiers , gdb@sourceware.org References: <030e3603-12ab-d3cb-afe7-2628acbc18e3@jguk.org> <5e3daadd5ee841b6f6d4ba4948849fa53ffe2107.camel@skynet.be> <9cbff50e-5268-98a9-7648-af53bacc1940@redhat.com> From: Jonny Grant Message-ID: <53594350-729f-4098-3cc8-225e536045da@jguk.org> Date: Mon, 15 Jun 2020 22:28:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, TXREP, T_SPF_PERMERROR 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:28:49 -0000 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