From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CP83NMzRkGhBxwMAWB0awg (envelope-from ) for ; Mon, 04 Aug 2025 11:29:16 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=bJZASnUi; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D03E61E102; Mon, 4 Aug 2025 11:29:16 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-10.1 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 1E3511E091 for ; Mon, 4 Aug 2025 11:29:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 78D703857BB3 for ; Mon, 4 Aug 2025 15:29:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78D703857BB3 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=bJZASnUi Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by sourceware.org (Postfix) with ESMTPS id 2913E3857C58 for ; Mon, 4 Aug 2025 15:28:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2913E3857C58 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2913E3857C58 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.12 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1754321317; cv=fail; b=BfRB7ihQT//cUTkzj6F/yQ798xmp3tRx4T75FYx5XvNl17wnV6wLnAkJZmzKI2oWxwIkWeShFW/IDfxmrJyTzvxg2cqgnqUMisKCh5BcjbiXsZqATVcCguQsfG3pVF/QyVDbXhFAVjJQdJrSZ/NgsNY5499pKu5+baqt8b+MRWc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1754321317; c=relaxed/simple; bh=pJkZa3iPCcKG6ACPROUQKb+uH6T5sRUBGygqTz78UN4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Ah0Hb2/Xq+6xhztUvZUJ0xpxhKnh1MI/twENFQrmDlV8+fzy/7uY5qAyjheQiqvw3gXKivAF2KmdiOCpmu85HZ62ceLJ8kIKD7oDYaOh+jNq1XCTn0f7ycKHKngTCjQIHvSva3AZDJJkNJfTz6HRvudg0gS47JOar1MGMoOWFTQ= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2913E3857C58 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1754321317; x=1785857317; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=pJkZa3iPCcKG6ACPROUQKb+uH6T5sRUBGygqTz78UN4=; b=bJZASnUi+FcZ2TWHLSJ/8StR/J3T34/+2mSNoZEH5zmf1HLMR15rJI/E B3zceASEMUfAJ22cpMh30HdiTfT2qe7+lK7JaBSY/1VglkWR7hWclB+aX A2vlGpV3JGAoO24hIQFluUqnZ+Ca6OTy+mPyXcWaLeJO/XXfVqNVqbVGH Q0zDXrPvvu2mWZeCuea1qD7LP19b13+Gh0rOcDBEzQXtMrdoqlyQ6IndR zdw2nS964IJibOZ/1/yNQFxV1QLABcpkFXFwugsUQYTRlxkNAMv8U1neu kWeriB2iNUFZnn89hLYPC7MSN7z8xYtzLP9CRt/Lwl1Sd0hlOsShP8CTK Q==; X-CSE-ConnectionGUID: zjCZ6m5URvO6ybdse8uR3Q== X-CSE-MsgGUID: aYsAEj62T4+7X5l0ItooUQ== X-IronPort-AV: E=McAfee;i="6800,10657,11512"; a="68044715" X-IronPort-AV: E=Sophos;i="6.17,258,1747724400"; d="scan'208";a="68044715" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2025 08:28:36 -0700 X-CSE-ConnectionGUID: bJSWCiPoQZayXWpFDI04Wg== X-CSE-MsgGUID: R0ZsPH35Rw2FFgv9hz83Sg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,258,1747724400"; d="scan'208";a="195130738" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2025 08:28:36 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Mon, 4 Aug 2025 08:28:35 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26 via Frontend Transport; Mon, 4 Aug 2025 08:28:35 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (40.107.92.43) by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Mon, 4 Aug 2025 08:28:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZdwMI/C9EWlOvhjVCxlTHxRdlmay3MTuz0/zk8Rz93WP/5hbKLZg6/se7k896MciI1Aum5OHglSTDdu7N5LS5Xqkj/a9PUikKNIdgfaReallVUfkdDMb5dpzjfsiLpvxlXE4slIF4mKxK6Ieu1sJHPORD4J4Ds6UbJ8jwLgcvMSukE0TpZ9TIOu5KlQHbc0WxvqCZj/FmFr0ScprXgl7pa805aV3eJiZ+BcA8YiIjOnwhuk0eumFSEGYyawzV8LmOPYEu2mxDObH23RwWhDV32oh9Bf0s6GKJjVnuJK+E+sp6Mr27BxJziE81bnetoo6wTDdSSXz1NS6nXqiLutshA== 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=HsMfrH4wE7+BTzdoM5dD/hOCss8U7Lc97Dj6ji7UuUc=; b=ee2umFIjnB+zDlcg960fgun4aj0lsDsgAn28iGclyI4K/wplyN1gfqw9c3i9/9Vw2mRk3fPwAEI3YxjEg3oUD0LXAdrC8JREvwltcfHkLRbOijFPgiQBZGDCQRhvIgH+21nKoOXxNmRT0XVL5KmG/Cp/6E0cye6FCg44D4eZAedATFVVCyxeugqUcidr9uBT2ov/XeZa3XJRo+MoOTe1ANHa7BfX2wV0L9ELq0S5x1rY/jpKcZjZNTsjPFoKyCjG5q6MqbUGoNQAkWo93LL6KHHtLwk+/qL76HEH5xagMQ4tR7ttBBPmYilws5vbk6/y0o/M8yCjxECNrfkPMJa6PA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from SN7PR11MB7638.namprd11.prod.outlook.com (2603:10b6:806:34b::22) by SN7PR11MB6728.namprd11.prod.outlook.com (2603:10b6:806:264::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8989.18; Mon, 4 Aug 2025 15:28:33 +0000 Received: from SN7PR11MB7638.namprd11.prod.outlook.com ([fe80::25b8:16dc:755e:34d1]) by SN7PR11MB7638.namprd11.prod.outlook.com ([fe80::25b8:16dc:755e:34d1%5]) with mapi id 15.20.8989.013; Mon, 4 Aug 2025 15:28:33 +0000 From: "Schimpe, Christina" To: Thiago Jung Bauermann , Andrew Burgess CC: "gdb-patches@sourceware.org" , "luis.machado@arm.com" Subject: RE: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack. Thread-Topic: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack. Thread-Index: AQHb6AdfopZEH8KoZUSF1KMGj5X1tLRJXyMAgAC62TKAAIloEIAIE9sg Date: Mon, 4 Aug 2025 15:28:33 +0000 Message-ID: References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-8-christina.schimpe@intel.com> <87o6t3cawd.fsf@redhat.com> <87tt2u788x.fsf@linaro.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN7PR11MB7638:EE_|SN7PR11MB6728:EE_ x-ms-office365-filtering-correlation-id: 88093b47-0db4-46bb-99ce-08ddd36b92a1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?hYCXB+EVlLEKUK1bN4X66rlP08eercNZ8W4i20QPnbJEIVSxHWpa46+V/oCU?= =?us-ascii?Q?K1cbcaW8sK4yhjfQL+0VqNffMrjd96QfW981/DnXtUdN9QT6Vfhybx1N3rBe?= =?us-ascii?Q?kXexp+C1Bw+1KWjNbtK1xWyjkYlMWVL4omVVVEHlMI2bpTZ6VnPxwNQsbo6J?= =?us-ascii?Q?hHhNFIMiFTua++UDWTb1JR4ek2BycxzPOC9+qJRMfJSCMIZkJURcNqDevrkK?= =?us-ascii?Q?yS5x3ohdDI8c8852Zj9mZRCGlxD8McH9aEi9labk06zJeGpgC7pWBmWD89LG?= =?us-ascii?Q?6XewwB5kjU6rhXhWZghGJiIwj+ftwHIoUozXylf2D9ovn8KWZ8vW+LCMbkaE?= =?us-ascii?Q?vQlusepgC/6wfhiMlEOdK45yu6nB6xPe6jd/ZlcI4+284WphXN6xrEGBqJ2F?= =?us-ascii?Q?tFY9zpkfNOamUc0xUN7OEuexXqsIJrhxvSbqeuFz+dlMOY8DbWhSpR5vF2N8?= =?us-ascii?Q?Sowzxlov9paWq4OWJrEPCh13l2ACMeJhHaThLhH/wcMT6gfYTpDw4VX39Ied?= =?us-ascii?Q?zj3IDv6cHewendsmE3uEOTzKwPRNk/B7yjtzbPB8Aj2DXpxSLznvjiTD4MYK?= =?us-ascii?Q?ZsZGZfKip2DteGKXkdaH0XAyvJNWrJXvjYvQloIMnsyz1ZTFb7LMZV9bl9Zv?= =?us-ascii?Q?t2abCo6eyffGFIaxPAfzdrSl5Z8GWysq8SKvUc7Q9f78ey2mZlTm2ra3nLxq?= =?us-ascii?Q?4PRi7RjaDGmE65RVwbI3mIFVYgSQ9AsAhAMomEoilumtKVqvV7Gm+Tj8uQGe?= =?us-ascii?Q?r606EvEi/UR5cACwmlvN2rYPuDETlw4sjO7myVtUeSQTqFyQL/HmrU8Dw3av?= =?us-ascii?Q?T/rUhYu9Qi2opilQGb8YNOjizgcMIf/Gqthr91JDK+1aWGEtJe4CGMEP2mAx?= =?us-ascii?Q?N52xFzh5DQolg+qpvQSbZeTrzRrk8R11k94JqJimLPdHzpEhY3Yy1WXJA0VS?= =?us-ascii?Q?o79D1r1iE1NCKprdEu5SDqs030mCBpVKTNNZcXV/0JWK5wT6AY6Jhor+lZvM?= =?us-ascii?Q?bLKdZsUiYQCw0yEUfuCsK1xfl5UaUNOKEwoujZOAIuoEf1RCz7Y9sIlXJ4cV?= =?us-ascii?Q?/eLfDdrdSTrv42NQPOaq+cn+H10mdQlJxbbFQNb7K7tFsf04jyTvle/aWWFl?= =?us-ascii?Q?vnZYJPFx2Vf2/TECE1wuDR/Qw/37vwyZ4GCFqcX7tflVDa8JvwAr6foS9GM/?= =?us-ascii?Q?iHkffwtMCeGap9BrIHwMf8cZJ5mxIpXiRtX98qUg9V2nur+ZrEhkl0QgUVQx?= =?us-ascii?Q?2CVUeVRMi+9nGjN0KsFimCGbyrsk5BYQiFysdwZ+rmDf46gwU5wqwh3gOwDO?= =?us-ascii?Q?2L0a60/eEWOKeK60LdbIx2v8UTUu0jl3X98BjsTCL79OhLtVkr1uzdZ8WVN+?= =?us-ascii?Q?Ah3z8cZuMqePqJUnHJ39rgHSSjMp8UnWKVUx1AD2wL1Jo2FV5yKUsyz6qNq/?= =?us-ascii?Q?5BM+hTwUe9QhgddtnGhqkCI3Fe+bhI1e?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN7PR11MB7638.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?wqIpIF7g7n1xM3DLzYaeqxo4hFQi/inSg9D67PWJHyRNmDyvRMLqKvKZINzm?= =?us-ascii?Q?VvTs6WJRCh9MomLU3Ipeo9Q+g6v/BW59qPnb1jfhqRTvciTNBhC0ICG94E9N?= =?us-ascii?Q?aB6Zi5xfn8pdRo9PuyLKgSh9AEzpzjZEL7WVrw0omesWb/0f0GYFejqA1DUk?= =?us-ascii?Q?hGQbm6c37Xk9DG0/vSbrg7Vj0La+SlndSg9hDqw3OYxWs3ZZAVxXLvTgPzG6?= =?us-ascii?Q?w38llGACd9e+r1adsnZ5QoRxt6bLFmhjcKECzWsacqyj78SzcGNKesBW1xgY?= =?us-ascii?Q?9GIIEr7AF//HYrB+0vPgLD10aPvlKdRAbzsCJW8x6Nsi03+ZR33Y9W3HbWwU?= =?us-ascii?Q?0AMDyg4EnY0iIoZrah54v7Fpi0LUKh65mSoDI3jpI51cZuXmyzmw8DUe2dEA?= =?us-ascii?Q?HqmQRLkpunHedHjZeUlcRBiCxqYZxCNsoh4jfbKZAJLW+SA5UWolztjAWCwg?= =?us-ascii?Q?XpM/6hpSW9Ef6BGwDbgudRdclh3c4XgX1rQjSID+D4bL25VUiFjg6MgPyXWn?= =?us-ascii?Q?yIT2EWIaxZOoCcAbyHlK4fz0sX9kmb5m7VEeaswOEC3beNvVzzm8iWzN7a+8?= =?us-ascii?Q?MxRMnNpRhdbAgnBPMi5YEG/AKUWl1DAZcTddE3C/oujeZTYUJHFEj9ZMTNLz?= =?us-ascii?Q?2hPoh5BxYttvYEphO5u8Xk+jtEMsGZuqCjfB+0/kQLa76yOJuoJx9G8TKF37?= =?us-ascii?Q?zwCCSWAx4SeHB30rThHxeYhiUFRPvysangjy4NR79y9TYGciyOLU5GtP9q5W?= =?us-ascii?Q?SBISpaYUGii0fTv5B9+Wl4mxqGe7sn7o7Q/HxEu3FeJz2Xnc4rGllzSkC1N1?= =?us-ascii?Q?Qhx7jWSpgCXNcZf7nAan3snz9MS1wZIUPwEKY1v2Ui9/mqv+W3Efn/DbibO8?= =?us-ascii?Q?jv52uVxd3CTtqj6A8vhPCyrzOZcvzfJvZwAdzRCYCAkvdbxNaB98GmB+L5UF?= =?us-ascii?Q?dev2/NoJkAeEEccAEXV9jlcucshXsdTlmfhFh5oFK9/vUwNlgEsJewKU8TNx?= =?us-ascii?Q?afjAfaGIvwyVlCVAMJQSmvotZbRnayBnLztJp1c58MpAXnruK0r2VDwtE0gc?= =?us-ascii?Q?kvxTrdchCcISCEqJz2SXBOxTiVXBRYQ9f0EBp7L9PT7Yx+Ros8H4X3vVztxm?= =?us-ascii?Q?CY7H4ufIZe2nyymbVkkTuG6n7epJZ7UAWtknrTFwXTXECo+lPwTX3m10ovEn?= =?us-ascii?Q?0nig9RRj7q/NI62BikU3xubc9dGVcE/jgZAbKSl+hPm2aXmOIk/DwQqDhJAL?= =?us-ascii?Q?5tQN9jn4/E88+J3zwZbSCRTGpikyDA+vEaSrI7VMHbrChmRAJoHlWOOKSPGI?= =?us-ascii?Q?cuww2ckfaCgwlHwBC/rriQ+1OrFe8OylTMdRYBXJH0XuVLaA2xl2NrZuH3v+?= =?us-ascii?Q?aPmy4g0LLLdKA/O7YCtSJtsaprTwKzXC28y/V0YnsejLceDOYnNu7XiUGE6B?= =?us-ascii?Q?dw11rzgkhEDxtPbmhqboKs+x5gmR6oodsVYPx1nFyZcEqXgHhX0tzMKVjCmq?= =?us-ascii?Q?xueIoRI0aQnKNwGTTwcpYcY0RYAJNw6NlhP0DTIPqfRSh6blYCSMjkXgEpu7?= =?us-ascii?Q?8ICWQlHHYs6E/1ro1r0qxWfJcHPovPVGI0Vt6XhtZt2GUXuo6ojRRierbIg1?= =?us-ascii?Q?jw=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN7PR11MB7638.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88093b47-0db4-46bb-99ce-08ddd36b92a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2025 15:28:33.1031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x4YF9v0wHw6+72GracHWeKcS3Ym7/BWOOWFBA28VLErW38p5A7CbKWdILqiI9nPb5h/Dsy8+P5uKzQt45058tjUbYp54HY4RkVa2D2gtPvM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6728 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable 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 Hi Thiago and Andrew, Now that I have tested this a bit I actually have some more comments on the= test. > -----Original Message----- > From: Schimpe, Christina > Sent: Wednesday, July 30, 2025 1:43 PM > To: Thiago Jung Bauermann ; Andrew > Burgess > Cc: gdb-patches@sourceware.org; luis.machado@arm.com > Subject: RE: [PATCH v5 07/12] gdb: amd64 linux coredump support with > shadow stack. > = > Hi Thiago and Andrew, > = > Thanks a lot for your feedback. > = > I should have mentioned that I created this test based on the test code f= rom > Thiago's series GCS core dump tests. I only mentioned it in the cover let= ter > so far. > = > I'll do it similar to Thiago when he based his return command testing > (aarch64-gcs-return.exp ) on CET shadow stack tests: > https://sourceware.org/pipermail/gdb-patches/2025-June/218895.html > = > So I'll add a comment in the test description > = > # Test the shadow stack pointer note in core dumps. > # Based on the corefile tests in gdb.arch/aarch64-gcs-core.exp. > = > and also a comment in the commit message > = > --- > The code and testcase are lightly adapted from: > = > [PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control > Stack support > = > https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html > = > in the next version. > Also I'll fix my test based on Andrew's feedback as described by Thiago > below. > = > = > > -----Original Message----- > > From: Thiago Jung Bauermann > > Sent: Wednesday, July 30, 2025 3:55 AM > > To: Andrew Burgess > > Cc: Schimpe, Christina ; gdb- > > patches@sourceware.org; luis.machado@arm.com > > Subject: Re: [PATCH v5 07/12] gdb: amd64 linux coredump support with > > shadow stack. > > > > Hello Andrew, > > > > Christina based the testcase in this patch on aarch64-gcs-core.exp > > from my GCS patch series and your comments on it also apply to my > > patch, so I'm replying on account of that. > > > > Andrew Burgess writes: > > > > > Christina Schimpe writes: > > > > > >> + # Generate the gcore core file. > > >> + set gcore_filename [standard_output_file "${testfile}.gcore"] > > >> + set gcore_generated [gdb_gcore_cmd "$gcore_filename" "generate > > >> + gcore file"] > > >> + > > >> + # Obtain an OS-generated core file. Save test program output to > > >> + # ${binfile}.out. > > >> + set core_filename [core_find $binfile {} {} "${binfile}.out"] > > >> + set core_generated [expr {$core_filename !=3D ""}] > > >> + set os_core_name "${binfile}.core" > > >> + remote_exec build "mv $core_filename $os_core_name" > > >> + set core_filename $os_core_name > > > > > > I'm wondering what the point of this core_filename / os_core_name > > > stuff is? My reading of `core_find` is that the returned > > > core_filename will be '${binfile}.core', so this whole thing feels > > > redundant, but maybe I'm missing something here? > > > > I wrote this part. The answer to your question is very simple: I don't > > know what I was thinking. I just deleted the last 3 lines from the GCS > testcase. > > > > >> + > > >> + # At this point we have a couple of core files, the gcore one > > >> + generated > > by > > >> + # GDB and the one generated by the operating system. Make > > >> + sure > > GDB can > > >> + # read both correctly. > > >> + > > >> + if {$gcore_generated} { > > >> + clean_restart $binfile > > >> + > > >> + with_test_prefix "gcore corefile" { > > >> + check_core_file $gcore_filename $ssp_in_gcore > > >> + } > > >> + } else { > > >> + fail "gcore corefile not generated" > > > > > > It's better, where possible, to avoid having pass/fail results that > > > only show up down some code paths. > > > > > > In this case it's easy to avoid having a stray 'fail' by > > > restructuring the code too: > > > > > > gdb_assert { $gcore_generated } "gcore corefile created" > > > if { $gcore_generated } { > > > ... etc ... > > > } > > > > > > Now you'll always have either a pass or fail based on the gcore > > > being generated. > > > > Good idea. I did that for aarch64-gcs-core.exp. If no OS corefile is found we will see a FAIL here. The usual coredump testing doesn't fail in case the coredump file is not fo= und. So all gdb.base/corefile*.exp tests have sth. like: set corefile [core_find $binfile {}] if {$corefile =3D=3D ""} { return } This can happen in case corefiles are managed, for instance, by apport on u= buntu. Do we want a different behaviour ? > > > There is also the helper proc `gcore_cmd_available`. I'd guess for > > > any > > > x86 target that supports SSP, gcore will be available, but in theory > > > you could consider using this to avoid a fail when gcore is not > > > available maybe? > > > > In the GCS core testcase, I moved the gcore tests after the OS > > corefile ones, with an > > > > if ![gcore_cmd_available] { > > return > > } > > > > in the middle, and after that I had to redo some GDB setup: > > > > clean_restart $binfile > > > > if ![runto $linespec] { > > return > > } Do you also do the "continue until crash part" again? It would make sense to move it into a proc then: ~~~ # Continue until the expected crash at the return instruction. proc continue_until_crash {} { global hex decimal # The line with the hex number is optional because it's printed by the # test program, and doesn't appear in the expect buffer when testing a # remote target. gdb_test "continue" \ [...] ~~~ And my gcore testing now looks as follows: ~~~ if ![gcore_cmd_available] { return } clean_restart $binfile if ![runto $linespec] { return } with_test_prefix "gcore corefile" { continue_until_crash set ssp_in_gcore [get_valueof "/x" "\$pl3_ssp" "*unknown*"] # Generate the gcore core file. set gcore_filename [standard_output_file "${testfile}.gcore"] set gcore_generated [gdb_gcore_cmd "$gcore_filename" "generate gcore file"] gdb_assert { $gcore_generated } "gcore corefile created" if { $gcore_generated } { clean_restart $binfile check_core_file $gcore_filename $ssp_in_gcore } } ~~~ > > But I agree it does make it more resilient/correct. Thanks for the > suggestion. > > > > >> + } > > >> + > > >> + if {$core_generated} { > > >> + clean_restart $binfile > > >> + > > >> + with_test_prefix "OS corefile" { > > >> + # Read ssp value from saved output of the test program. > > >> + set out_id [open ${binfile}.out "r"] > > >> + set ssp_in_gcore [gets $out_id] > > >> + > > >> + close $out_id > > >> + check_core_file $core_filename $ssp_in_gcore > > > > > > I'd move the blank line after the 'close' personally. > > > > I also had that layout. Changed. > > > > -- > > Thiago > = > Christina Christina Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928