From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uZqdDz1LrGpWFhgAWB0awg (envelope-from ) for ; Thu, 17 Sep 2026 16:19:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789676349; bh=KMp0r2diPAPVrfG5J9qMFpkrbr9EwFwututyJ5GsZN4=; h=Date:Subject:From:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=gprkwihISe8snHSIJs5smvmIb3k15UOHU5c94wnoKdYo49gWOtmHt2GZLVyEaMe5m OTt9vJysOezfw4gjEiaxBrXg1QHwtMK4qXQjaNqno9oUv4HiwKxMzTeNbTRLJmyqUn w4BAyH6tgk/yI8/lB5YjPJwayLdY2wm60HT6J0uw= Received: by simark.ca (Postfix, from userid 112) id 36F921E06A; Thu, 17 Sep 2026 16:19:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=O32j3r1U; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 193191E051 for ; Thu, 17 Sep 2026 16:19:08 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9BDC04B9DB74 for ; Thu, 17 Sep 2026 20:19:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BDC04B9DB74 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=O32j3r1U Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 893CA4B9DB74 for ; Thu, 17 Sep 2026 20:18:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 893CA4B9DB74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 893CA4B9DB74 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789676322; cv=none; b=JSWdLHbjJYr6FSc248bWgMao8Csss6CrdyucjMY4HLwj3Lr99uSW43fQk8kITuS2xdqQ5f8cAA4HssJ4X+UbDVuq7kV7A8eEQD+Gmv07+N6cPj0OS7nYE20aDprH9JowXbOOWgJ9KxtZ1Z51X4jXvT51JvEeD0pJz19LC0MJaX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789676322; c=relaxed/simple; bh=KMp0r2diPAPVrfG5J9qMFpkrbr9EwFwututyJ5GsZN4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=wY6PdwLQF0Q92eJCU2H2J4hbUP4jaYig4JXhm4RM2SQNoADYrGyjgSQ5q8O0+CSIHYRVzsFSn7FTAfejAJA0+xUXmypqInKo8xhijlA53mu7UFZlg4W/Wg+H7oTax8EJeJd3S7ULma0EEWpw6TYIMM+j30Lrl3cY9QndmFAK5VA= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=O32j3r1U DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 893CA4B9DB74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789676322; bh=KMp0r2diPAPVrfG5J9qMFpkrbr9EwFwututyJ5GsZN4=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=O32j3r1UnbDbr3fM95au5/n757PpACcM7q2yz5WEhWQ2q627BYhkUMLru/VIy42Sn wSszxEVQXjoktYBZre4DYsXXK50yc+ySNBE2y0xtAfeAjKQ9zMOPqW+HliyIyc+EoY xNuEEyh3PMOgaSjz5e+XzH2DQm0KXIXWh2szltWM= Received: by simark.ca (Postfix) id 2C4BD1E051; Thu, 17 Sep 2026 16:18:42 -0400 (EDT) Message-ID: <219e0d45-3769-4647-8b07-f1c098a8a6f0@simark.ca> Date: Thu, 17 Sep 2026 16:18:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb: rely on the first non-exited thread TPID when reading Linux procfs files From: Simon Marchi To: Matthieu Longo , gdb-patches@sourceware.org Cc: Thiago Jung Bauermann References: <20260824162155.467233-1-matthieu.longo@arm.com> <49282a00-e09a-48d1-8b88-9f197b397453@simark.ca> Content-Language: fr In-Reply-To: <49282a00-e09a-48d1-8b88-9f197b397453@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 9/17/26 11:43 AM, Simon Marchi wrote: > On 8/24/26 12:21 PM, Matthieu Longo wrote: >> On Linux, /proc/ is keyed by the thread-group leader PID. When >> the leader has exited, some /proc//... entries become unavailable >> even though another thread is still alive. This can happen, for instance, >> when the main thread calls pthread_exit() and another thread continues >> the execution (existing test: gcore-stale-thread). >> >> This causes GDB to fail to read procfs entries such as cmdline, cwd, >> exe, maps, and smaps when it uses 'current_inferior ()->pid' after the >> thread-group leader has exited. >> >> Fix this by adding inferior::first_non_exited_thread(), which returns >> the PTID of the first non-exited thread of the inferior. Use its LWP ID > > No longer true (it returns the thread_info, not the ptid). > >> when accessing procfs entries that only need a representative live LWP >> belonging to the process. >> >> This is a best-effort choice of a thread that is expected to still exist >> in the target. Since GDB's view of the threads list may be stale, the >> selected thread may already have exited by the time it is accessed. >> Callers must therefore still be prepared to handle that case. >> >> Update the following functions: >> - linux_info_proc >> - linux_process_address_in_memtag_page >> - linux_find_memory_regions_full >> - linux_fill_prpsinfo >> - linux_address_in_shadow_stack_mem_range >> to use the first non-exited thread's LWP ID instead of the inferior PID >> when constructing procfs paths. >> >> Add a new test in gdb.threads. >> >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31207 >> >> Reviewed-by: Thiago Jung Bauermann >> --- >> gdb/inferior.c | 12 +++ >> gdb/inferior.h | 11 +++ >> gdb/linux-tdep.c | 90 +++++++++++++------ >> ...access-procfs-while-thread-leader-exited.c | 48 ++++++++++ >> ...cess-procfs-while-thread-leader-exited.exp | 78 ++++++++++++++++ >> 5 files changed, 211 insertions(+), 28 deletions(-) >> create mode 100644 gdb/testsuite/gdb.threads/access-procfs-while-thread-leader-exited.c >> create mode 100644 gdb/testsuite/gdb.threads/access-procfs-while-thread-leader-exited.exp >> >> diff --git a/gdb/inferior.c b/gdb/inferior.c >> index 8c619ffec5a..f6d77799ac2 100644 >> --- a/gdb/inferior.c >> +++ b/gdb/inferior.c >> @@ -250,6 +250,18 @@ inferior::find_thread (ptid_t ptid) >> >> /* See inferior.h. */ >> >> +thread_info * >> +inferior::first_non_exited_thread () const >> +{ >> + auto it = this->ptid_thread_map.cbegin (); >> + if (it != this->ptid_thread_map.cend ()) >> + return it->second; >> + else >> + return nullptr; >> +} > > I was thinking that it would make more sense to name the method > "any_non_exited_thread", since there's no ordering of the threads > (ptid_thread_map is an unordered_map). > > Then I saw we already have the free function > any_non_exited_thread_of_inferior. It doesn't use the same strategy to > find a non-exited thread, but the intent seems to be the same. > > But one thing it does is that it prefers the currently selected thread: > > /* Prefer the current thread, if there's one. */ > if (inf == current_inferior () && inferior_ptid != null_ptid) > return inferior_thread (); > > I think there is a bug there, because if the selected thread is zombie > leader (which happens in your test), then it will return it, even if it > is exited. We could fix that and then use that function. > > I'm thinking it would actually be nice if GDB prioritized the selected > thread for /proc access here. Most things are the same for the whole > process, which non-exited thread we use is not important for those. But > there are some things in /proc that are thread-specific (things like > stat counters I tihnk), so it would allow the user to select one > particular thread and then get information about that thread. > > I am trying it, I'll send something soon to the list. Here it is, could you please give it a look? https://inbox.sourceware.org/gdb-patches/20260917201755.589524-1-simon.marchi@efficios.com/T/#m8b6bd53bac36790acc05b7475512c6d94b762a53 Thanks, Simon