From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wboTJOc/T2owSS0AWB0awg (envelope-from ) for ; Thu, 09 Jul 2026 02:29:59 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=HqutQxhK; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7F4F81E098; Thu, 09 Jul 2026 02:29:59 -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 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 8A6481E04F for ; Thu, 09 Jul 2026 02:29:58 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 21DEA4BA2E3E for ; Thu, 9 Jul 2026 06:29:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 21DEA4BA2E3E Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=HqutQxhK Received: from mail-yx1-xb129.google.com (mail-yx1-xb129.google.com [IPv6:2607:f8b0:4864:20::b129]) by sourceware.org (Postfix) with ESMTPS id DAD954BA5435 for ; Thu, 9 Jul 2026 06:29:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DAD954BA5435 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DAD954BA5435 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b129 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783578574; cv=none; b=R2cRvmE8uQujxZm+mUeim5bu4HIY970sPibhKI6yQcUHIJvUMYKJJiHinyOeKxJyXeHpnAGNER8hSSX4UgMZ2z3dLybSeCpQoBrROJiPukoXUrtJWwUown/K7q/mZGVAFqdlcYYQ28yE+zZAGw4r5x54x/qnVTxbaePJjYyDV+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783578574; c=relaxed/simple; bh=oMukaiymQTrnafA9O6/Pw1FEnkukTWwhWaIkq3dm4oU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xap5nZbRff1qoHCzTYWpuQWqV+MUYnjqUPoMn4TG+WPvxvYxnIej+vTfHJJBnmRbeC1nJh0SbidEcQiErmfaiBT8uQx/bBKWEnOj6ycovjf8HnPPfXGgmueUtVYVpY/Dfm9lkZYIhi6Ddg5jHyk+TqJIPdrUhPfbcVqJYA5coPA= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=HqutQxhK DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DAD954BA5435 Received: by mail-yx1-xb129.google.com with SMTP id 956f58d0204a3-66771ded50aso1754142d50.1 for ; Wed, 08 Jul 2026 23:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1783578573; x=1784183373; darn=sourceware.org; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=TY3y3EOZ4Is+DXn3kbhjDMO3OiOBER7R+PaMAaUCQp0=; b=HqutQxhKWfRS5V/8+CqHDtqI8nz4+i1j+DA5G9kaE45uFdImLjOrU59RR/2JjUAEuj tSxsncXcE77TEiYJ0UHBNJqK3DUWxNpSVl4KAkE4XL6SyJtGvzDdx98nCNhuyqE1JM6r ZwBNL/8BYJe+RLoqFg/2fSRGbvHsyhe/IBPdwEoiI69iPXolwnvXlTES34DUZaan6WBO ETBAJp6Bk0a8MFJsDlt03ZC2H15QpywfUV7nIcCRY0IIX2GeUxSfAktb5MeF2oHhNDMI +DIxJS8l85AS5iOpu5yaosyEZkmQRe/wiXzAorfrn6GGQhxZGz2KWW2KQbX7RNkGLc09 RkyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783578573; x=1784183373; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=TY3y3EOZ4Is+DXn3kbhjDMO3OiOBER7R+PaMAaUCQp0=; b=A1LXbspM9lpehoGUHY4dwXgLjdZXRBvZz/IzUnTxyKApJ0oARkx4SJiet+xQd6bBt6 r3U2L4klfPJC85ePUmv0xL1/vH+/W82zK6ifpBGUrdt8zpXeGUYyniFQn+z7Uq1UJ53O BY7zc5+qeRBEBheVo7iFcpeFFNP3tyfHtw62gPt6RtHMWpxQOM9tCJHGYQlN0kjVRXdD DnSujAqYBQ6Xcw2d7gu/eEFIbIarmomHylpXwQjK/6uqOKp/gAU4zmFHtf/ARTOLIk7l jlzcFBd0lPP/PFYODbA0rgUdU91Xte+vxazgXX/3Omuc+ym0/BY2faSfIkq0YLsZUA86 vkIg== X-Gm-Message-State: AOJu0YzHksed5m/IR4XxiFEAtEUH9dreJ+TyS6s/eeB5slLyLxoZRgPn 8EWdTcVTYujLMP4sGFhg/UUPe1d6oEciTz5Gw/zahxmDHcjlq8DBXMy0BYRXoDehZoM= X-Gm-Gg: AfdE7clDAuOVcRNKbuNfrDf2kMmRN5pdWFsEGSQsjYMnu4m8tjfoxfiQIYTYVKxasLA oayWP39OKAX2Xozo5G9K5WfSh2vUulSfu1Ni4tzYB/ywArYy1k3B4thBIWKMbS4sILKG8tFH/ZI 1FeONsAwvgcNovaoTPKaxhiFW+vwmRgHIuKIb8Xk8tILetPrjlm2Q89a7d4rJeugB3vnPmnQ+jB YqKTpkD5pg3W7zhFhz4xDxCn2eqyRutU9EP3ngiaEBkI0bVyg2xX0Vzdg0Y1ltHL/2Ifoll56PI YXQE2H4gjeIYkYZMUdRVihcyUPJARQvrKW0g1ALC/+o57wnN1HU5YxYlgYwLV75tP8eGai0Nn8/ zWg7qa26jqgNgjLgzHlGtTsWI8XhaaBkWP2SNjloGUTeDhaJGLVK1VtYxR0EDyW5s7H6hNgEsT+ iMXsRXHVle2rPbRCaqnfo7gES2Kca+HPzteA== X-Received: by 2002:a05:690e:1444:b0:667:b089:fe6c with SMTP id 956f58d0204a3-667b08a0698mr2914595d50.57.1783578573044; Wed, 08 Jul 2026 23:29:33 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-66787b23b35sm3463190d50.21.2026.07.08.23.29.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 23:29:32 -0700 (PDT) From: Thiago Jung Bauermann To: Matthieu Longo Cc: , Luis Machado , Luis Machado , Andrew Burgess , "Yury Khrustalev" , Pedro Alves , "Tom Tromey" Subject: Re: [PATCH v1 02/10] gdb: rely on the first alive thread TPID when reading Linux procfs files In-Reply-To: <20260707154900.94542-3-matthieu.longo@arm.com> (Matthieu Longo's message of "Tue, 7 Jul 2026 16:48:52 +0100") References: <20260707154900.94542-1-matthieu.longo@arm.com> <20260707154900.94542-3-matthieu.longo@arm.com> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Thu, 09 Jul 2026 06:29:29 +0000 Message-ID: <87o6gg1xrq.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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 Matthieu Longo writes: > 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_alive_thread(), which returns the > PTID of the first non-exited thread of the inferior. Use its LWP ID > when accessing procfs entries that only need a representative live LWP > belonging to the process. > > Update linux_info_proc, linux_process_address_in_memtag_page, and > linux_find_memory_regions_full to use this live-thread LWP ID instead > of the inferior PID when constructing procfs paths. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31207 > --- > gdb/inferior.c | 12 ++++++++++++ > gdb/inferior.h | 9 +++++++++ > gdb/linux-tdep.c | 38 ++++++++++++++++++-------------------- > 3 files changed, 39 insertions(+), 20 deletions(-) It's a pity that the patch originally proposted to solve this bug: https://inbox.sourceware.org/gdb-patches/20250412201140.31510-1-dominik.b.czarnota@gmail.com/ was approved but never committed. But your version is more comprehensive, since it also makes the change for other procfs files. It also explicitly looks for a live thread. I have a couple of comments below, but regardless: Reviewed-by: Thiago Jung Bauermann > diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c > index 155d6e874d9..b89f4ee0717 100644 > --- a/gdb/linux-tdep.c > +++ b/gdb/linux-tdep.c > @@ -842,9 +842,7 @@ static void > linux_info_proc (struct gdbarch *gdbarch, const char *args, > enum info_proc_what what) > { > - /* A long is used for pid instead of an int to avoid a loss of precision > - compiler warning from the output of strtoul. */ > - long pid; > + ptid_t ptid; > int cmdline_f = (what == IP_MINIMAL || what == IP_CMDLINE || what == IP_ALL); > int cwd_f = (what == IP_MINIMAL || what == IP_CWD || what == IP_ALL); > int environ_f = (what == IP_ENVIRON || what == IP_ALL); > @@ -859,7 +857,8 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, > { > char *tem; > > - pid = strtoul (args, &tem, 10); > + auto pid = strtoul (args, &tem, 10); The actual type of pid here will be long, right? Unless there's a an advantage to using auto, I think in this case the code is clearer if the type is explicitly mentioned. > + ptid = ptid_t (pid, pid); > args = tem; > } > else > @@ -869,17 +868,17 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, > if (current_inferior ()->fake_pid_p) > error (_("Can't determine the current process's PID: you must name one.")); > > - pid = current_inferior ()->pid; > + ptid = current_inferior ()->first_alive_thread (); > } > > args = skip_spaces (args); > if (args && args[0]) > error (_("Too many parameters: %s"), args); > > - gdb_printf (_("process %ld\n"), pid); > + gdb_printf (_("process %d\n"), ptid.pid ()); > if (cmdline_f) > { > - xsnprintf (filename, sizeof filename, "/proc/%ld/cmdline", pid); > + xsnprintf (filename, sizeof filename, "/proc/%ld/cmdline", ptid.lwp ()); > gdb_byte *buffer; > LONGEST len = target_fileio_read_alloc (nullptr, filename, &buffer); > > @@ -901,7 +900,7 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, > } > if (cwd_f) > { > - xsnprintf (filename, sizeof filename, "/proc/%ld/cwd", pid); > + xsnprintf (filename, sizeof filename, "/proc/%ld/cwd", ptid.lwp ()); proc_pid_cwd(5) says: In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3)). I think it's ok to leave the code as is for consistency, but it's worth mentioning this detail in a comment. > std::optional contents > = target_fileio_readlink (NULL, filename, &target_errno); > if (contents.has_value ()) > @@ -911,7 +910,7 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, > } > if (environ_f) > { > - xsnprintf (filename, sizeof filename, "/proc/%ld/environ", pid); > + xsnprintf (filename, sizeof filename, "/proc/%ld/environ", ptid.lwp ()); > gdb_byte *buffer; > LONGEST len = target_fileio_read_alloc (nullptr, filename, &buffer); > > @@ -935,7 +934,7 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, > } > if (exe_f) > { > - xsnprintf (filename, sizeof filename, "/proc/%ld/exe", pid); > + xsnprintf (filename, sizeof filename, "/proc/%ld/exe", ptid.lwp ()); Same comment here. proc_pid_exe(5) has the same observation. > std::optional contents > = target_fileio_readlink (NULL, filename, &target_errno); > if (contents.has_value ()) -- Thiago (he/him)