From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wIHbIM8+sWoK9CwAWB0awg (envelope-from ) for ; Mon, 21 Sep 2026 10:27:27 -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=Wd35QRMw; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=Wd35QRMw; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 754BC1E051; Mon, 21 Sep 2026 10:27:27 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED 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 749C51E01F for ; Mon, 21 Sep 2026 10:27:25 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8A9FB4BA23F3 for ; Mon, 21 Sep 2026 14:27:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A9FB4BA23F3 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=Wd35QRMw; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=Wd35QRMw Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazlp170100001.outbound.protection.outlook.com [IPv6:2a01:111:f403:c200::1]) by sourceware.org (Postfix) with ESMTPS id 4A18E4BA2E3E for ; Mon, 21 Sep 2026 14:26:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4A18E4BA2E3E 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 4A18E4BA2E3E Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c200::1 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1790000813; cv=pass; b=ftCbIKbKNTnoqHJDNKU+OASFGKPl6Ai2y3sWKWltRbT2P9Q5+0XLEZv+THbpvqlnVucrYWuMq32mRasP3IHjQqbqRCfbFtYZ566lo12gi0SFyp/gLzy1QB1dFHhrakZLj6HzB8aLNRBqjhYmjCRMQzh/dXZ+XsKhIA/I/jdlpIQ= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1790000813; c=relaxed/simple; bh=+TYqwavUUR0NzWIFznRVoWNJtTuUjWHZY510Rai3vWQ=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=PaMpqWwzvKJca4W3wphgA7KU4ItRcTi4w2bwZeBiVUq9CwDer7+t0vnHPozlhCTm1JAyXViJwa56H1p9GWrZuvgcziwfHlvxOk34F5z7iU/TU3XYJ3cDyQ7XQN5O1F1ZvwbEgIX0WJnZvisP/oyVJeneMjt0rims2Pbs5zevAkY= 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=Wd35QRMw; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=Wd35QRMw DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A18E4BA2E3E ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=il+aWoGPuFRcLT8eyZg5SDsoqdG8ReyX7US/xGFhwdudS7qkj5FLStO6fyxaErs81TADSlfiotKKtAP8ALUWQGhHXPHRLG5BNgO27zvAyd7sVRPm5qP1k1wv/OGchqz4By00pZT59sAHWXoE1Kns9kAnKjyQMtRFvGCWAzOV2Xa553H2ylrP4g8ic56dIIzuAuh4zpxvF90W4k4AAuMhOph0IaU2kdv0KHAvTUOmjlIzLxtg9Eo0GDs4dilFfA+5NbiuPzIMyXpITcfsf7bLBaR+idY7YFFRANKJcVcbuvv0y/WTjbd7dP2m/JBTHuGjtI1AmT1BalZ2xhZM40ZUYw== 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=tcpxNfUs9qAOa6kb073hI003tS16UAIuRhLOKu43gTE=; b=ufv2PxmHhnQ5AqqKr1j/WZUQEXRiKO8+oyehYOceviagdXIj11l6jxFR/j6XT+v3xdwcUqK+Cg4EDetAEqRdZCk7E45oXkJKJpUJ4YIgimOYVMIjjMK0QhMYE6MggBkdKve6HLFmoWAji7zzgd+VQ6Qm8CpPNsOoI24Cz4Eq44j7vS/kxE/Vu3BbtkbCUFILQCqskn2x4TrRKtJklWSRuAr4DM1/9GstdNFES3PcCNWmEa3w+v9qPPrTkugbsr1Q525h6jLobDN7OGlzAdkl4ilI0ndmJx/J3B88+/74lWov48DRtynUUUCtX+Xuk4psVb11wf4yTFg7L9/tnfy31w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=efficios.com 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=tcpxNfUs9qAOa6kb073hI003tS16UAIuRhLOKu43gTE=; b=Wd35QRMw0KkKMk3QLXy/4qZ/kry4mrzca66PfwOWcicBLlbzmBszbt6R32wsVJkhTbVNjWF5y/awqleg+DY/blInRvkUitkCV0J52L3Ie6/tBrVEY0ILAuBTp+0626HFoErEt9xz8ZMQF8sLMItxUT8GHk+ZOpLvEcaGDuqmQVg= Received: from DUZPR01CA0306.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b7::16) by AS8PR08MB8085.eurprd08.prod.outlook.com (2603:10a6:20b:54a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7; Mon, 21 Sep 2026 14:26:42 +0000 Received: from DB3PEPF00008859.eurprd02.prod.outlook.com (2603:10a6:10:4b7:cafe::8d) by DUZPR01CA0306.outlook.office365.com (2603:10a6:10:4b7::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.16 via Frontend Transport; Mon, 21 Sep 2026 14:26:39 +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 DB3PEPF00008859.mail.protection.outlook.com (10.167.242.4) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Mon, 21 Sep 2026 14:26:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lb0ZQUmtkmNaaej7zD5CfZunJuTUQ/Gn1gKi259Mnw940nIpI0FCS9ZLkJZo3+vbY7qK5BT5bFHiuqq42XoEHrzZgBYzIp4TmQ4+/Bqk3nfhDoSjUCMe53UmHOr7pBlAmPnwmrLDuDuqnp3Hv4C4mgsn6aycjYG674fis7QQGiT0NCAe4CzPctEXYEAGsmqUppKp846QLDIh2xyRdpRO5bDTX0ojVzUsy7XVhhe2g6qokrNHCRhRApxReswn0BivtG94vW65RqBvbLKGM02i1zP/RlNbCZWCgX5Rte/Yy2EBW6HvC3jlX/1GPHskLcCDPsp3eL+yPn8IIoE0umo8Hw== 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=tcpxNfUs9qAOa6kb073hI003tS16UAIuRhLOKu43gTE=; b=KPfdi+9YsxOM8kM8EOVCeUzJ5m3e++3Tqn8VEgB7wVEHnWHuJkLmokXGwU80fXeegcSGq5thYft9lfzmvXpxBltJuCilq5GzSGCPYNTME6NIrH8Vk2ueaWqwBDSCCtgWaE+jYKcDPWbhtuEuopL0l/rjeywdn7X7RY7YQg7O47byHDI1hEymVq2dphBqVMboBv1JrF+io2jJqPg6GfmOodjTC5Eh87keALmbZWLoOaEWsQfxaUaTPA35XJxw1H6v1P6K23KdlGx6YaBkY6f4HbflRzaAdXtvNp+XJ6cBQ1zaCbmp467WBxxt8x8nYSPxGe7GbSngMOoPyVGVZ+/xmg== 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=tcpxNfUs9qAOa6kb073hI003tS16UAIuRhLOKu43gTE=; b=Wd35QRMw0KkKMk3QLXy/4qZ/kry4mrzca66PfwOWcicBLlbzmBszbt6R32wsVJkhTbVNjWF5y/awqleg+DY/blInRvkUitkCV0J52L3Ie6/tBrVEY0ILAuBTp+0626HFoErEt9xz8ZMQF8sLMItxUT8GHk+ZOpLvEcaGDuqmQVg= 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 DB9PR08MB7747.eurprd08.prod.outlook.com (2603:10a6:10:396::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Mon, 21 Sep 2026 14:26:03 +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.0451.012; Mon, 21 Sep 2026 14:26:02 +0000 Message-ID: <016bc26f-7889-4267-9a7e-00d152bca960@arm.com> Date: Mon, 21 Sep 2026 15:26:01 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] gdb: use the selected thread's LWP ID when reading Linux procfs files To: Simon Marchi References: <20260917201755.589524-1-simon.marchi@efficios.com> <20260917201755.589524-2-simon.marchi@efficios.com_5b6b04a9_release> Content-Language: en-US Cc: "gdb-patches@sourceware.org" From: Matthieu Longo In-Reply-To: <20260917201755.589524-2-simon.marchi@efficios.com_5b6b04a9_release> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0097.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:191::12) To AS8PR08MB8659.eurprd08.prod.outlook.com (2603:10a6:20b:563::10) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AS8PR08MB8659:EE_|DB9PR08MB7747:EE_|DB3PEPF00008859:EE_|AS8PR08MB8085:EE_ X-MS-Office365-Filtering-Correlation-Id: 084e9bea-be8a-4326-f3b4-08df17ec5899 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|1800799024|366016|10067099003|56012099006|6133799003|18002099003|22082099003|4143699003|11063799006|5023799004|13003099007; X-Microsoft-Antispam-Message-Info-Original: 6NCZTyj/eSi0b8YegkWz0HdoJHL1vyKPSXpjhBuv+B7OiOB7pta90t//axgIEyQ/ks7hYdSBrq2mpdkDgkwrs3jxYFtCtHvpdmWBnGijaY+JIVhX924lP/ZCKZncVZ6euqwK3Om+AIEKBeuji4K917PjPsTE6rJyvCOEwIbBUqwrrkAoMnNTu3zJh81eNqsm4eF5Tfnz3g5Uta7H+eIB+sZdPMWFYB9FIB7YibrJbmwc+Jur80MeoPlh8ycpIKO5UcnZrxOhIOFcyEQLfcHclIMZ84Mj0xCcvhCtH6kUnHLsocKkckucKT2nX5xktrCNv0SAX0AVWu4g7DyeN3sRBIFNuA/hLx5AHMN0cknN/P86rTyqCXeYonB1IgKznTjnoYLgZXAPRE4E9II2wlEyKqzu9TIB/KQZkAydBkru67QJmNjU2op9ydwhq84kvpAI9XjY0KKRWAY1Lo9kNSiQ402W2U2j1gn9UI/KacPwouuf3yjJ/CyNtAfIQhdudQaWZ8VB8Q1Jy+kcRyVy1RHpGIlYLmHLBbH5M7KUnRasOHg5TCtsgStadjJByxGE2qm1S9h3hMyleaPa7H/+ogvlXNCKFXm9Aj5zne+8Hdn7AW0= 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)(1800799024)(366016)(10067099003)(56012099006)(6133799003)(18002099003)(22082099003)(4143699003)(11063799006)(5023799004)(13003099007); DIR:OUT; SFP:1101; X-Exchange-RoutingPolicyChecked: n2PlNKUv/oNi/RsmP0mXs7pjqmlH6PixZyGyptOTwDdgPOvBuDUhKekl7AcDkRok/XXePEUlVDmpYU4sOrxWCHQj8HIFXnwJ4smpNNrurDpKHfQTK9+d4QEZGxatTn7mSzRmmN0btvGHovAEnRhK453DRp4SqVwy2Sa1B3NC8lT4dWVl+OrRMaoNvBFuOMfLVP9OqpfbjCmxVYzgl35DGh5MzYrMV4NhCEyTEJTtVWkir65z0m14aW8I90pyX2gJDnD4s8YWU2yPe18XWX3wjdiHL5xocdZZ2h06KrMaln7WvwNX9GTYjpvFbSYgdmEyqGJVoRatIzhY3QjlOop+3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7747 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB3PEPF00008859.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: c0270ce2-648e-43eb-234b-08df17ec436a X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700016|376014|23010399003|14060799003|1800799024|82310400026|35042699022|13003099007|6133799003|11063799006|10067099003|5023799004|56012099006|18002099003|4143699003|22082099003; X-Microsoft-Antispam-Message-Info: 0y4M+1+Pn4Uwm+v+bC42yHH2Szg1yUxaQs/4GMnxlfSGAXpzuklpielOxQv3fiCv3Knx7ges3pPHp0bxQ+osTPY+j0aYV1ToZvHTrkXdAp0UDLSSsdH2hwmxKVw0eLjxIJW6+DkXRWHbO1R0HOy5MKa/EuYGu++ZVZOguCjIOmQrNazH0QlO5DK9iALROahFkyz9pRGdqdCOpgXwmOeUBUP0A4oKT/6zJOmOMqaCLrdnn4rOOc4v4DfbLttBPHkx2EhMfpJhNDRR+TSl+gY5YkP+CIFrX51DQIjFONPvqfMlUtFPsxPOirHgpaI53k0wONmfo9/LwER7LuxQ0gn9hQ4CmLYXWlfccgd+Hz5JXz++nqBsJB7xZmCjDFnH8QOUDUy1G7iYOPb9kFEYeb9Ht+CojESGn2qxsjxjaptnfA2BmphNVm1k6AjSJ39siPlTTrd0/kZXojQQWlgRHZDLALuRbKFRZLGsonnRy1ged7PsHO/+hscX5uJ4J6ORJ//KlzRuR18BE3FDmrqNYmd70NTPv9VEcCwfOuYZlRoiby6dlu5fyAHHM+12E+oKT+JvuoOJTn0Q30SmOIltwmX/nsTZ+rbImzoLV/GRol/qiLp2sU81/H/SaKihurJf32tKueKBHh5LoE4qAhGDz6uisA== 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)(36860700016)(376014)(23010399003)(14060799003)(1800799024)(82310400026)(35042699022)(13003099007)(6133799003)(11063799006)(10067099003)(5023799004)(56012099006)(18002099003)(4143699003)(22082099003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: aAGLoVvNrTBpVM1n+1Znl67L/S1FBWu66Bgg3SkQQLJsXS33fDZdgEqe1XkRGDCYNfkOSA0KpztSJiGmd7uR+B94xXcx5YscVbazOX312eXJu5yDdP1OUkecMm9UqHkfQYnefXoI+DvmMP2wWczOLmUzyF99Xr9kUGbsStW92xO42mbIbrbceuNmpjacCgpmw0U6ns7qB5Yt1Pp35cHJtbFYHklZDsAVapu/NDlyIvFQsmCvxwVATjZ9gtrnkydzreqGkQcKhtQsIkHlpVqiw+zOq4peBMPNBCe0/tVdAXidn3JeMvMek6xr5irtVs39r4dfaJ5N0dZ5FoOVEXPUoZk6Z6XEJdTM+ZvNY8nY+BjnWQmDQ722uNsmjj20cQCJLi7VIAK5imjZxzitD36Z/2vfwn2S3bjUU2giefuVPxV7/NJNNyCvwK34GOmvNZi1 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 14:26:37.5540 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 084e9bea-be8a-4326-f3b4-08df17ec5899 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: DB3PEPF00008859.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8085 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 18/09/2026 13:21, Simon Marchi 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, renamed below). > > This causes GDB to fail to read procfs entries such as cmdline, cwd, > exe, maps, and smaps when it builds the paths from the inferior pid > after the thread-group leader has exited. > > A /proc/ entry exists for every live LWP of the process, and for > the entries listed above its contents are the same as those of > /proc/. Fix this by building the procfs paths from the LWP id of a > thread GDB believes is alive, rather than from the inferior pid. > > Add get_ptid_for_slash_proc, which returns the PTID to read from, and > use it in places that read /proc: > > - linux_info_proc > - linux_process_address_in_memtag_page > - linux_find_memory_regions_full > - linux_fill_prpsinfo > - linux_address_in_shadow_stack_mem_range > > linux_vsyscall_range_raw also reads /proc, but I did not change it, as > it uses a different pattern, "/proc//task//maps". It could in > theory suffer from the same problem. > > The thread is chosen with any_non_exited_thread_of_inferior, which gives > preference to the selected thread. I think this is actually a good > feature. Some entries in /proc (like stat and status) show some > thread-specific content, so this lets the user pick which thread "info > proc" reports on. Most entries are per-process, the choice of thread > makes no difference for them. > > linux_fill_prpsinfo is an exception to the above. It populates the > NT_PRPSINFO note of a core file, which the kernel (for kernel-generated > core files) fills in from the thread group leader, even when that leader > is a zombie: > > https://elixir.bootlin.com/linux/v7.2.5/source/fs/binfmt_elf.c#L1901 > > To keep GDB-generated cores looking like kernel-generated ones, it keeps > reading stat and status from the leader's entry, so the values taken > from those match what the kernel would write (stat and status are still > readable when the thread is zombie). Only the cmdline is read from a > live LWP, since trying to read that one from a zombie leader doesn't > work. This mirrors the kernel's fill_psinfo function, which takes the > program name and arguments from the mm of the thread doing the dump: > > https://elixir.bootlin.com/linux/v7.2.5/source/fs/binfmt_elf.c#L1530-L1539 > > This also fixes a bug, in that core dumps produced while the leader is > zombie would be missing the NT_PRPSINFO note. linux_fill_prpsinfo would > read an empty string from cmdline and return false. A user-visible > consequence of that is that loading back the core would not show the > expected "Core was generated by..." line. > > This is still a best-effort: GDB's view of the thread list may be stale, > so the thread selected to do the /proc accesses may actually have > exited but GDB does not know it. > > Since the entry "info proc" reads is no longer necessarily that of the > thread group leader, replace its "process " header with: > > Reading /proc for process > > or, when the LWP differs from the PID: > > Reading /proc for process (LWP ) > > Since "info proc" now stores the pid given on the command line in a > ptid_t, whose pid field is an int, reject a value that would not survive > the conversion, rather than printing one value and reading /proc for > another. > > Update gdb.base/info-proc.exp for the new header. > > Rename gdb.threads/gcore-stale-thread.{exp,c} to > gdb.threads/thread-leader-exited.{exp,c} and modify it in a few ways: > > - give the program a second worker thread > > - check that we're able to read /proc on Linux even when the leader has > exited (and is selected) > > - check that "info proc stat" reports each worker thread's own LWP id > in its "Process:" field, confirming that "info proc" prioritizes the > selected thread > > - load the generated core back to verify that we see the "Core was > generated by ..." line, and therefore the NT_PRPSINFO note was > generated > > - enable non-stop using the usual save_vars / append to GDBFLAGS > pattern, which fixes a pre-existing bug of not being able to run the > test on the native-extended-gdbserver board. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31207 > Change-Id: I1e6ccfae90551b8e96a5644b51c7652bbda593fa > Co-Authored-By: Matthieu Longo It looks good to me. I ran the 2 patches on the top of master, on both AArch64 and x86_64 on our internal CI and I found 2 failing tests on AArch64: step-over-process-exit.exp and missing-thread.exp. I re-ran them manually and both of them are passing. This has nothing to do with your patch, but are those tests known for being flickering ? This is the logs for step-over-process-exit.exp: ``` maint show target-non-stop Whether the target is always in non-stop mode is auto (currently on). (gdb) next [Thread 0xfffff7fc0020 (LWP 291431) (id 1) exited] [New LWP 291431 (id 3)] [Thread 0xfffff7e0f120 (LWP 292049) (id 2) exited] warning: error removing breakpoint 0 at 0xaaaaaaaa087c Command aborted, thread exited. Cannot remove breakpoints because program is no longer writable. Further execution is probably impossible. (gdb) [Inferior 1 (process 291431) exited normally] FAIL: gdb.threads/step-over-process-exit.exp: which=other: next (timeout) ``` VS when it passed: ``` maint show target-non-stop Whether the target is always in non-stop mode is auto (currently on). (gdb) next [LWP 1540 (id 2) exited] [Inferior 1 (process 1539) exited normally] (gdb) PASS: gdb.threads/step-over-process-exit.exp: which=other: next ``` It looks like there is an issue while removing breakpoints. At first glance, I would say that there is a race condition in the test when thread 1 exist before 2. And this, somehow creates a time-out ? Regarding logs for missing-thread.exp: ``` continue Continuing. [New Thread 217413.218469 (id 2)] [Thread 217413.218469 (id 2) exited] warning: command aborted, Thread 217413.218469 unexpectedly exited after signal stop event Remote communication error. Target disconnected: error while reading: Connection reset by peer. (gdb) FAIL: gdb.replay/missing-thread.exp: non_stop=on: missing 1 thread log: replay_with_log: continue ``` vs when it passed: ``` continue Continuing. [New Thread 1692.1693 (id 2)] Thread 2 "missing-thread" received signal SIGTRAP, Trace/breakpoint trap. 0x0000fffff7eb6ce0 in clock_nanosleep () from /lib/aarch64-linux-gnu/libc.so.6 (gdb) PASS: gdb.replay/missing-thread.exp: non_stop=on: with unmodified log: replay_with_log: continue ```