From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uVF1MGlaVmokAwgAWB0awg (envelope-from ) for ; Tue, 14 Jul 2026 11:48:57 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=i7P4XTSk; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=i7P4XTSk; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C18D11E033; Tue, 14 Jul 2026 11:48:57 -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=unavailable 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 055A81E033 for ; Tue, 14 Jul 2026 11:48:57 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8F7104BA2E36 for ; Tue, 14 Jul 2026 15:48:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F7104BA2E36 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=i7P4XTSk; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=i7P4XTSk Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazon11013007.outbound.protection.outlook.com [40.107.159.7]) by sourceware.org (Postfix) with ESMTPS id 56A214BA2E1A for ; Tue, 14 Jul 2026 15:48:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 56A214BA2E1A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 56A214BA2E1A Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=40.107.159.7 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1784044106; cv=pass; b=ORj0v6RkaN/Wx1x4SMi7x8B4f6zuUXsOwEa0lW5dFe481MlzmaxQ5g0JJww/EFAgIGzmBqgStdX/WyP/zB/bi9O9tK0K8D8ocvLViQuNBD1jooEmLfD7xq/kUuD79Qy1jzVZsf0rtWcgrUPEvQvRVWktZAaQXVhjMASF+gM24vc= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1784044106; c=relaxed/simple; bh=ux1IchUm/KVJV1ZasE8yT8Vx3O69viUX/ERqJM6Hac4=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=iTxr2+kz1TVBmYSpPgTVfd2unnRVjbUTsgFir+1mzxNDbgR5Z7Qg7YpXtQR8zSOAoZ5l6Cdjmb3pveU/g6286AzAwIGZSBMY3B7KtBQGDEOgDlJKTv7riSLia6GG0y3J/vNY+BxlYqRnwq52srNb0JZIBxHMxc+qfg9akOS1b20= ARC-Authentication-Results: i=3; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=i7P4XTSk; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=i7P4XTSk DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 56A214BA2E1A ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=alT6qfbQZP72MEFem+A/IMqakdkP9ZoLqn/FnCh4ycFL7nffu8eP/PiupHmzf97eyBLlJECiO2WOiw+F4PApGka7gibeara+stoRgPpkYNWuUSmtkWYpxeYBDJP0U9rEBQIHQDu4Y9UOSOltKjqg5yuIIN2Lt5Ejiuh12FpHOBvYWBQP47ooFpxNCBnqg2ehl3ncapUwJBn20LpnmmGk5q1HFUC/u/xCfS20nBBiz4fqZlEJN0e9iVR9vL8Vvq95fC7UHn0uQ0cT25icynAN55L7r3yN6lIlmsx2kfB39owOYbNM7tI4AnYorWmhSj7mu4PZDOjyuKomMfWJy29lFg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MeQzdF4d+4Jj5ULlQL2cShhetRQEQFtMweXz9TsChL4=; b=reT4RHKEluyuCfHdT4vCddG2b9IDjYJNpHmq7qlnmyKtlxaLwJYzlolTs7tvfKNRRaivSe+gvJksJ2q3JTH+LQ+xXqLOViHMDKH12VbhpwHby65+eNMQivbTZLJeFES8KebTLTB1PtS7DjrXy0Nmk7okOV7fQqaMKuNOYQlMMFOzTPQaNLIT92POKjixxxrWnjJTZgBoIHlAEQyFU215yJpmCoravoYHF7ECv0ftzVQorIfVZ6pvWElYrOLmREwFxu5WoURycBR3lFH1nheuLc9GzlYfRSmVczPQgYu3Qi39nAs8kx9vsZtt2BhG/Wdid9JTN7MSRJ9jz1dcdoVeiA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=simark.ca smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MeQzdF4d+4Jj5ULlQL2cShhetRQEQFtMweXz9TsChL4=; b=i7P4XTSk8sFH8arwQlJoI1zskpUGWKUsWAgCBoDdZp3q6Sla005MvAet0DseAOshh6kV851y4FG04RGfuG0dlkHKifpsbpDCHRMzaiU/nd+gXXYWh/bCgAcEjrVCBcEPPapSCxSWz2e1BNI1dPd5Fbf1sulXPI31c5nhJ/J7NnA= Received: from AS4P191CA0024.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:5d9::18) by PA4PR08MB6048.eurprd08.prod.outlook.com (2603:10a6:102:e6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.13; Tue, 14 Jul 2026 15:48:14 +0000 Received: from AM4PEPF00027A66.eurprd04.prod.outlook.com (2603:10a6:20b:5d9:cafe::5a) by AS4P191CA0024.outlook.office365.com (2603:10a6:20b:5d9::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Tue, 14 Jul 2026 15:48:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM4PEPF00027A66.mail.protection.outlook.com (10.167.16.91) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Tue, 14 Jul 2026 15:48:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HbloxmmMGy8p5P91ltB98Ewt1b7ZLMxPCFpW44hySvzYJkv31gaa0qNat/mcXv52Awqm1sC4+I8b6XOWJ8A/yMVvzB8JVn+JQdcbxUA/g7J53YEwxe+c4m3tTmp5A/MxL3ipSy8Gar6PrRCJCjFT8JnXMbXsmu0uog+V7Ci30Gr6mG8vg7cMfXwB2Kes21vaMztbTJ0P32CDmIxiAcD0oHowYkwojk8+sOqM7kb/xiPBoBpRV2+h2qPMGIky3sWU6eoLHrMzjHH2Bu3jKcFVdFPlv15pOqDLyEkgfslDwAnNKTDHXcx34V7KOG6R75liqY8eHCcmOIdsS2t3SusjfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MeQzdF4d+4Jj5ULlQL2cShhetRQEQFtMweXz9TsChL4=; b=BYPZz036KxsOm6/G4mvpL6csvNIzUfWAmOKmmHC4f4R+v7CzcY5C3QJ/xYS5GLvcTnxvAgNRM9GlrAZvp7EhYBPQ59r5pcSjxjHNsyJTQQD2YwhmB7d6J1LE7YHdCmAAtZ9kco1y1jKnHnNkbZIZ1jWZVmi3ZqgZvuDFKOWAHOYBxmczG87CiTnhrB234bvu+lIPusByROanZYBfDp78hgIrbdygVrUu/lO8DT/+fAPjn5pjj7eoaKTKNo1h3Eezyh9mYV9aQZcrzeR5e+EZGNdAvH+FAs75Fd7LjAC7QCUN40VxsWJayX3mMbkFWI0/gH7PbD/MKXuMgb6jfJhXxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MeQzdF4d+4Jj5ULlQL2cShhetRQEQFtMweXz9TsChL4=; b=i7P4XTSk8sFH8arwQlJoI1zskpUGWKUsWAgCBoDdZp3q6Sla005MvAet0DseAOshh6kV851y4FG04RGfuG0dlkHKifpsbpDCHRMzaiU/nd+gXXYWh/bCgAcEjrVCBcEPPapSCxSWz2e1BNI1dPd5Fbf1sulXPI31c5nhJ/J7NnA= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from AS8PR08MB8659.eurprd08.prod.outlook.com (2603:10a6:20b:563::10) by DB9PR08MB7841.eurprd08.prod.outlook.com (2603:10a6:10:39c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.202.18; Tue, 14 Jul 2026 15:47:11 +0000 Received: from AS8PR08MB8659.eurprd08.prod.outlook.com ([fe80::96bf:2de3:5eab:70ae]) by AS8PR08MB8659.eurprd08.prod.outlook.com ([fe80::96bf:2de3:5eab:70ae%5]) with mapi id 15.21.0202.014; Tue, 14 Jul 2026 15:47:10 +0000 Message-ID: <33309d7c-ecd0-470b-9ece-f767b425fcbd@arm.com> Date: Tue, 14 Jul 2026 16:47:08 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 02/10] gdb: rely on the first alive thread TPID when reading Linux procfs files To: Simon Marchi , gdb-patches@sourceware.org Cc: Luis Machado , Luis Machado , Andrew Burgess , Yury Khrustalev , Pedro Alves , Tom Tromey References: <20260707154900.94542-1-matthieu.longo@arm.com> <20260707154900.94542-3-matthieu.longo@arm.com> <590655c1-abed-4a16-b8cc-762f1d8e6093@simark.ca> Content-Language: en-US From: Matthieu Longo In-Reply-To: <590655c1-abed-4a16-b8cc-762f1d8e6093@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0180.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:311::11) To AS8PR08MB8659.eurprd08.prod.outlook.com (2603:10a6:20b:563::10) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AS8PR08MB8659:EE_|DB9PR08MB7841:EE_|AM4PEPF00027A66:EE_|PA4PR08MB6048:EE_ X-MS-Office365-Filtering-Correlation-Id: 67c79afe-d203-4ab8-3f28-08dee1bf5084 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; ARA:13230040|23010399003|376014|366016|1800799024|3023799007|18002099003|22082099003|5023799004|56012099006|6133799003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info-Original: 2RpSYYV2JyArTpE0ZqhOJzKk5ZVsuo1c8/0l+/8h3pWGnUYgjJitaNs1nMWfYTHRemDZhxAhxh1vgsqGg4fHiNpm9A5uMwVzSoPDEF2+1xMhSRXopL67u7UKJ5IQBqwn31tEXftVQSsE2HzgtGl+Cwf4OaLVXiux8oBjGc0hd47U+hOmUTzmRKJsugZp7g1LzWb8+Bk6oEimFaO8JU2/UaVKyx+nS3MPnEugorKwTPN6Glu0IK15IEb05nyhXWe2uTuxQTc2Y6F4PXzNZd55cv42oqZgGo9awPj10ViGxiOx9JEjB665sv0BRdLFkpSU6ka6Z4Byp6ZXb7a1x4RpDvuvpujenpEq//HHzThjvBvnZ0NfqctRf5MBY7BKnIFgp1aZOa9/5KVRjmkLC6HgUPA1FRsoOfKYYmQ0/vQ09H9ilI4JnqlaLF2awtydvJNX5Wv7Kmb4oFtUVarDCXaxyNCQqhBtDksYMVCNieZ14RnbH1xFxiU1VBWRes4we0/fEOqKLUJIYbHpPV5/BNPnCnwwMFqN9a6f4dZViI9Gbe22NvYbu7948qdj6h2BHBXVXCeBUkQKp22l6Fax06a/6G5NDDF47APYC6pVztjzjMTOe8gWudqy1J+j/z/XzrDa5VKkA7Zj2jnyLMTei7IPixTirqEIRWiTO9RdexqhTJE= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR08MB8659.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(3023799007)(18002099003)(22082099003)(5023799004)(56012099006)(6133799003)(11063799006)(4143699003); DIR:OUT; SFP:1101; X-Exchange-RoutingPolicyChecked: L/N6egUJXxqoHfJdyElKtUgeN/idSLxN6TcNX/GtyZrZjzcAU5VD3B6FjaREUxh8ca2U3Fgyo59Nku2M3zSLAcoG1c06gnw6N3uokdbeGleoEWwqLOQUJN9Z7RZSvgbA7aNb5m2agLU+l8y8OEzW2CJdVGcCSQXkBomQmQ2J8GrzSQVAh0U5G28dwXNlwglnwlmLwmGp9BlDqE/mpWOjZbC8vU7a6IGQlZegPoVnYz82nfVXYtpQXvc3fputoGVYmVvu+wTMrR+kfW+vH4sxHLeWRV1ePJlzmXZHGkMCeZFwrcAYTZxswSARFM2AAN2dmvVEEXyE7OuwxrOFvB/7MQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7841 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00027A66.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d445198a-42b4-475a-12e6-08dee1bf2a56 X-Microsoft-Antispam: BCL:0; ARA:13230040|35042699022|14060799003|1800799024|376014|36860700016|82310400026|23010399003|11063799006|56012099006|4143699003|5023799004|6133799003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: 3aJSyD0iCwa4uHxlzxsGyWuci8VFZYhRngr7gM10oogm+shCDTbVmB2id/j5Qs9J4JkjxGp8PgIryCQZeh7zqK5O7XHQb05t5Yx3DKg0mKSxdTMEMAokp2qKv2H9mil4XlHFqdvX6ZdzReNn0o/LvZ5rCPCsIHPo08L9XOK2Ge0zJErqnitnAXFqVs/H8vZKbQzcXyiMYnvIFMd0akUKY1smYwdQUbxWT90kdQmumPqPAUsW31K184M4w8Fcch7+vodshw07+2C8GTFfIJleuYljsE1g+kMvHrq0dQceW9X/2n+A2HbidZBoLByThSTvhpJyRrgICfEVum5ZRsdDWGsU8lJt4MZxGcH+qyseX3Q9ilIUcvWYzLNXcIKBeAvaWOy6iaY3fU3pe2CIJ1lW61RkhavhIZ/09ek3YTU4BRhyPUS0oLJhZZS6oA76bT6KnFQ9i0ljCIV/lfKBh/2JwAwsDEcj3zN2r9PzjQAKhXs299+PaCtacD0g7p59ot5u7cOzXGSH0D9wmFyDjvfyc1uo+j6oI1qnpiTpNXagL7xLj27qortoJ4QnkQyW6gKpYTEHPvYuSN+tkmt/DZEwaQ0xjSb99rI7HO2K6ifvYHnbDLhn12jWqtjlDoGjGsXeuWUoBPGZUNcMsl54jRDzFIA4pyCZBNgIUlN+ZGzgX+cPHK3uSmj++iZM3GRh8hh63/plE1WMwoAWEzz0cLIlsQ== X-Forefront-Antispam-Report: CIP:4.158.2.129; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:outbound-uk1.az.dlp.m.darktrace.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(35042699022)(14060799003)(1800799024)(376014)(36860700016)(82310400026)(23010399003)(11063799006)(56012099006)(4143699003)(5023799004)(6133799003)(18002099003)(22082099003)(3023799007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BtdfrlIE3+oHi5N6PYxN+iChCqr2TjeTLusx01EMtAF2X05VqDL16fMFOQDCaHoYo3IhXZLn1oqDBo/04dvrakK3/oFkGreRU8Ret1NT1aJ2iHR4BrjLwMAstE1aK+voOjrGT6UA/5rblQLf2DxcNwAynjeIuvH/o1M1+urFIEa0WlwhaNJ6QQGDPFYo6SOHLJLEohsxsW6R4W8SNyC30GlUhcrXX2HjBVvJw5aTQzQ4pSBUApTsosjDATbHO/UC9x78jjt74PySaluW/F3cspzF1GXORx1eJoffJ1khT6jnP49fBNJ+cIgiNh9dpi+CxfIjL8csE83zFqltNIz+sDVRNMMZhQQuczsk24n/f6qOgJA5IMNtVEnshXepG0sMjpuPm0Qw4MQzTGjCdVyxulsC7Aap1Fj2l5VKg3IO7veonhaUinTWHtKVJOPv5gM4 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2026 15:48:13.8049 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 67c79afe-d203-4ab8-3f28-08dee1bf5084 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[4.158.2.129]; Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AM4PEPF00027A66.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6048 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 09/07/2026 15:24, Simon Marchi wrote: > > > On 2026-07-07 11:48, 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_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. > > First comment, can we have a test for this? I think it would be > straightforward to write. > Fixed in the next revision. > This is an improvement, but I can still imagine some cases it would > fail. A thread could have exited, gdb (or gdbserver) could have reaped > it status already, but the information might not have made it all the > way to the core yet. So the "first alive thread" you select might not > actually be alive on the system. I can't think of a way to fix that > problem generally, especially in the remote case. If GDB checks in > advance "is this thread alive" and then tries to access is, I feel like > there will always be a TOCTOU problem. > > I'm not opposed to merging a simple fix like this that takes care of the > most obvious cases (the main thread has exited, all threads are stopped, > and it obviously doesn't work). But I think we should capture the > shortcomings we know about as comments in the code. > I proposed this comment: /* Return the first non-exited thread of this inferior. This is only a best-effort choice of a thread that is expected to still exist in the target. A thread may have exited after GDB last updated its thread list, or GDB/gdbserver may have observed the exit but not yet propagated it through all layers. Therefore the returned thread is not guaranteed to still be alive when it is later accessed. This avoids the common case where the current thread has exited, but callers must still be prepared for the selected thread to no longer exist. */ ptid_t first_non_exited_thread () const; > Then, I wondered if everything we access through /proc is going to give > the same response when we access them through another thread than the > leader. I asked ChatGPT for a summary: > > Entry Scope Notes > ----------------- ---------------- -------------------------------------- > cmdline Process-wide Same for all threads; comes from the > shared address space (mm_struct). > > cwd Per-thread Usually shared, but can differ if > threads use unshare(CLONE_FS). > > environ Process-wide Same for all threads; comes from the > shared address space (mm_struct). > > exe Process-wide Same executable for all threads. > > maps Process-wide Describes the shared address space > (mm_struct); same for all threads. > > status Mixed Contains both per-thread fields > (Pid, State, SigPnd, etc.) and > thread-group fields (VmSize, Threads, > etc.). > > stat Per-thread Describes the specific task > (/proc//stat). > > smaps Process-wide Same mappings as maps; based on the > shared address space. > > coredump_filter Process-wide Stored in the shared memory descriptor; > same for all threads. > > For most of the info it should be fine, as they are shared between all > threads. > > For cwd, it's shared unless some threads call `unshared(CLONE_FS)`, I > don't know if it's common to do that. > > For stat and status it looks a bit odd, because we print "process > ", and then the line right below it (Process with a capital P), > which comes from /proc//stat, gives a different number. > > (gdb) info proc stat > process 1989928 > Process: 1991838 > Exec file: a.out > State: t > Parent process: 1989898 > Process group: 1989928 > Session id: 126340 > ... > > In any case, we could perhaps improve the "process " line that we > print to indicate which thread we obtained the information from, in the > "auto-select a thread" case. > Indeed it might be confusing, but still better than nothing at all. I propose the following change to the line printing the process ID. diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index 86532e1e0d3..b11473fd22d 100644 --- a/gdb/linux-tdep.c +++ b/gdb/linux-tdep.c @@ -875,7 +875,14 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, if (args && args[0]) error (_("Too many parameters: %s"), args); - gdb_printf (_("process %d\n"), ptid.pid ()); + thread_info *thr = inferior_thread (); + if (thr->ptid == ptid) + gdb_printf (_("process %d\n"), ptid.pid ()); + else + gdb_printf (_("process %d [Note: information where gathered from LWP %ld " \ + "as the thread-group leader (LWP=%ld) already exited.]\n"), + thr->ptid.pid (), ptid.lwp (), thr->ptid.lwp ()); + if (cmdline_f) { xsnprintf (filename, sizeof filename, "/proc/%ld/cmdline", ptid.lwp ()); Output before the thread-group leader exists: process 814 Output for any info proc commands after the thread-group leader exited: process 814 [Note: information where gathered from LWP 816 as the thread-group leader (LWP=814) already exited.] > Finally, linux_fill_prpsinfo still uses the ptid.pid(): > > pid = inferior_ptid.pid (); > xsnprintf (filename, sizeof (filename), "/proc/%d/cmdline", (int) pid); > > Should it be changed too? > Yes, it should. Fixed in the next revision. > And linux_address_in_shadow_stack_mem_range too? > Fixed in the revision. > Perhaps it would be useful to have a function "read me a whole file from > /proc" that takes an `inferior *` and returns a string, encapsulating > the logic of finding a thread to read from. > Please have a look at patch 5/10. There might be something to do there. For now, I will try to keep the change to the minimum needed. >> diff --git a/gdb/inferior.h b/gdb/inferior.h >> index 9c031035a23..305b1d31830 100644 >> --- a/gdb/inferior.h >> +++ b/gdb/inferior.h >> @@ -513,6 +513,15 @@ class inferior : public refcounted_object, >> /* Find (non-exited) thread PTID of this inferior. */ >> thread_info *find_thread (ptid_t ptid); >> >> + /* Return the first (non-exited) thread PTID of this inferior. >> + >> + This method should be used in place of current_inferior ()->pid for any >> + features relying only on the PID like the reading of procfs files. >> + 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. */ >> + ptid_t first_alive_thread () const; > > I think this comment is too specific to Linux and the problem at hand in > particular for this location. It should just say "return the first > non-exited thread of the inferior" or something like that. > See previous comment above. > Function any_thread_of_inferior already does more or less what you want, > but it prefers the currently selected thread, which might not be what we > want (we perhaps want to prefer the leader). That function could be > renamed to any_non_exited_thread_of_inferior to be clearer. > Fixed in the next revision. > I would prefer if you renamed first_alive_thread to > first_non_exited_thread, that's the terminology we use elsewhere. Fixed in the next revision. > "live" makes me think of the "target_thread_alive" target function, > which actually pokes the target to see if the thread is alive right now, > that's different. > > Simon Matthieu