From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cDyVKs3IpGckRiYAWB0awg (envelope-from ) for ; Thu, 06 Feb 2025 09:35:57 -0500 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=QycPNqkI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9F5C41E105; Thu, 6 Feb 2025 09:35:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 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 autolearn=ham autolearn_force=no version=4.0.0 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 44A511E08E for ; Thu, 6 Feb 2025 09:35:56 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D44413858424 for ; Thu, 6 Feb 2025 14:35:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D44413858424 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=QycPNqkI Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by sourceware.org (Postfix) with ESMTPS id 1176A3858435 for ; Thu, 6 Feb 2025 14:35:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1176A3858435 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 1176A3858435 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.18 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1738852506; cv=fail; b=TPs6OS+LrgdoRcYstTerIL3LIvvEFp2sL8GOrrl+OCK1tYjVY4kvLJ6vqv4RgZSqF1c6PU16sagnWoKQGp09m0wH5chNcoVl8RhNrOUTHl2IQygaT9IOLvorx2ZKPRhJWntw8P5CgD+xIAxdTMcQ/gM7FSIAXaOnoD5ehNJAjok= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1738852506; c=relaxed/simple; bh=5k/p0++Oc8Wqxj/chD/V+Vggc6oe8Rno45S9wDCSBGw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=S3fNirSDLlfQlCMfzNgYG3uhqa5+Fih7ovT4RF/1H39YqneuD0WXT2UdznfuC8M5ZwKVnTASnPwaPk+/yQXSJDP6mavbjlhE7ZXSjAf6ETIECortODMBsrpu48XUh7OCLjtpnCmci2Cc0RtlvXPAN73VegmSF7wLurYd6VODQtM= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1176A3858435 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738852506; x=1770388506; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=5k/p0++Oc8Wqxj/chD/V+Vggc6oe8Rno45S9wDCSBGw=; b=QycPNqkI7Gv5pCKDr/CNxKLL0QwLf4jirThGSXltkk0RtnlKUSAfwPql mhoTHM74195NXCVjh5fz94I2mimK2U80AP9N7eHHx1Ywt/VNa2hs9RNdi OWkwR6pcSY+w4JWl505dEJkr7/JNx1LJ3AjoDxj9+ER2CRihZJta3ndnX Ar0WYZWtmXp2U7fqTelaDLKTXESvfKE8kdABb2QHphoQlSduHoIHz+LgO B/QsAujkyhlwNhm9P2ouP6C/5AJN91aRliYEprF4vgMLAkYbaOkGakf8k liR26OFFLKlWcRYmUR+3gSfVJ3rG4V2fSucm7+zlzhRUB3VzwHxt5Zzix A==; X-CSE-ConnectionGUID: UQjDGrXARGGLkW8kpmLwSA== X-CSE-MsgGUID: OqilsAjzQtGu/hG5ToYEtQ== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="39570184" X-IronPort-AV: E=Sophos;i="6.12,310,1728975600"; d="scan'208";a="39570184" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 06:35:02 -0800 X-CSE-ConnectionGUID: iDIOJ73xSSW8b8jG2ALGdA== X-CSE-MsgGUID: gdwb6JV2SneEjgZqzECoXw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,264,1732608000"; d="scan'208";a="116255247" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa004.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 06 Feb 2025 06:34:37 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Thu, 6 Feb 2025 06:34:30 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44 via Frontend Transport; Thu, 6 Feb 2025 06:34:30 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.40) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Thu, 6 Feb 2025 06:34:28 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NVSwZseiYrF3ohpVrGEhgSUERHiEnYi3oGHZ99h3Ii4o8uATcLOqH//C5ezPy1BO9sQlgsGrPqA8sqFXcH7YFplZRZMOdgbviC4Z/VLUg6SMCXWrOU2TWygLLstfiR6au/YkhTOs0WICNXrMqo7F/Zees9KQ6vP8HL1oOWBDwXrAh6qRqInQNevmlouJXZQwwLFPyNT9ppeZKIgxyCwr60nmHaGFM0uwfz9qfrv6cYckAsrnT31QQdPsToTez/D8hPmOkKx5VT/ZlRQ2+L9kop0/XV8ER5HqLee3rihYzTOmNvI8+2TK9tQbEuBn3oeH1Ie9f09w+AjgpsFEY81HiA== 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=QfuGhlshxcvrcFaE/vd1ATMPXY+QkDBP9YtEsahqmLw=; b=gXkQV9oX+P2zdET70dhFKPcZJfl/UpXsYAlvhkvgD/FucvW0TRJjCTzx6E0WDg6TbB0dC1SVV+0yFAqIPpPIJHjHBSAoFbBPLOX0nFTzthDXXypQ5Yw6zQr3zPSKcjw5fORBZN3sYsXFNGIRLD+Z8cFaBwNxQkTypch0FAzgsq5xUiQakoNs4Yxi7jDVG8Bg9KrDuPAz+COi0kI7nKXjQslTV2btWB1ccVBLsAlfoZlmSYk8BoqUm0oZ2r3cNF8DH4pfVYLcTJNvCheKEjlt3GXJblSPXoa9netjlrsfmOMyXP4Uj+ly2RtTVUGgtYgIOxhPqGMgfiCImejUG6RGLw== 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 PH7PR11MB6523.namprd11.prod.outlook.com (2603:10b6:510:211::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8422.12; Thu, 6 Feb 2025 14:33:44 +0000 Received: from SN7PR11MB7638.namprd11.prod.outlook.com ([fe80::25b8:16dc:755e:34d1]) by SN7PR11MB7638.namprd11.prod.outlook.com ([fe80::25b8:16dc:755e:34d1%4]) with mapi id 15.20.8398.021; Thu, 6 Feb 2025 14:33:43 +0000 From: "Schimpe, Christina" To: Thiago Jung Bauermann CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register. Thread-Topic: [PATCH 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register. Thread-Index: AQHbUxvgLKyB2r9p7EKqT1NrHvVDLLM55Br2gACcViA= Date: Thu, 6 Feb 2025 14:33:43 +0000 Message-ID: References: <20241220200501.324191-1-christina.schimpe@intel.com> <20241220200501.324191-7-christina.schimpe@intel.com> <877c63ix3x.fsf@linaro.org> In-Reply-To: <877c63ix3x.fsf@linaro.org> 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_|PH7PR11MB6523:EE_ x-ms-office365-filtering-correlation-id: fe1e4f8f-7800-4f09-729a-08dd46bb4229 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|376014|366016|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?8U1d4VP1FvQ0F0MTKW5/ahXXYw1+pW7vsYO6WB4WNAAFzW9055hPyHu3p5/E?= =?us-ascii?Q?XmJy9qWCNk4wq7HUiQMXjQsTElg8GCqBv28uubmK1pKpydUKzA6qca8CVTDp?= =?us-ascii?Q?DHFQxz2s+TIni6gZgUW8OnW6+KAf6J+b3dbrkm39+QKhyHOZHN1eo03UuR5t?= =?us-ascii?Q?fUf3P1b5CW2VsrcE4ailangs6rR0yxpqQLxyo3l8v9+Pa3mVNBKhxiI0T/Gl?= =?us-ascii?Q?GsptazkClnGYgY9Mnl0V2LUkyin3NreutrgOPk3YAD7R/owY9hGFEkwgDxJ5?= =?us-ascii?Q?/q0oMT4XeDxYeLo/dOsN4oGTsgG3rLSycB0PPi3P/ewAmFEKrsxq3NOixnZk?= =?us-ascii?Q?IAjttT0Da8gYbcNDtekZg1NRxjQOOSMRaxnlqcqw1groabmLl1oCg0O9Yyr4?= =?us-ascii?Q?Ra4elcANqC/IgcvCI2x2B82QnLI9Q9LAGYy+r4EuVydjYSuiWDI3kPCwDGc4?= =?us-ascii?Q?Tkgf7ufgdTnDAguThI4KakLIYBLnhohc/YAcMpHRuHWyHpE/IuIMGhSNp+we?= =?us-ascii?Q?jj1dbEq6caGHoScuXQ1ziMzEZA6dTsMEEjqrYXYcqyS0w7QBypAfyvw0I0eN?= =?us-ascii?Q?rpBANjWfsb+8CkaNoEJCWbuBV+cD2Q1JWwRIco/qe6LOGyawjeMTVlIHeHtu?= =?us-ascii?Q?JuEmnZGLl6SrnhHClvqbLSv1iPb7iMmwKHVqiA5jJq0x2nCG0nCxLAKWFau8?= =?us-ascii?Q?XMHdEmG/7Y4KE6rBpQEcDtVXqVfpEyyaF55w75D2wQPdLsRxD+JhgdYnZlsF?= =?us-ascii?Q?fSJLSA/tHWHYhqmV7BBrcR0s7PwBbp2LAS1MuV+PSnRaWThuwdR4zDERu5FG?= =?us-ascii?Q?306HDykd9qTofBez2jUxRVShGyCmQWfMwrgEi01m+bKqQ+yOxmmU/QqqjNsU?= =?us-ascii?Q?OxPB2sMZFbW4Jo5SbNb7O3X1btUIK5ZoVBgi6hDvktiSPF3hqdtUYdx3G1qh?= =?us-ascii?Q?8IdLOvWJHqX9fbA7HJn3CoA20ANfggxWaaypXVqedmyF8hiPuJjLLpNwP87C?= =?us-ascii?Q?Y+pY/2iAmPCyjLCDD1GYa3eH/JCgfov60jQmKDE2F1D4NvlBFBVCNUZ7v/nB?= =?us-ascii?Q?HAgQWJLy4WSKcIYdtxGd/31Rv2q6aCHqZTdmdpY3dW1fRE0bfHg6isV6sXkW?= =?us-ascii?Q?4xOIXzjTX6PvdKusWsrmeb/pbx1sB+fzFM01lt84cao/pom3EXXEI8w9+ZzC?= =?us-ascii?Q?ECbxYg1/t7037+mcIiuUkFcF1UflTSVdG3TFi1ak2PchYLEg5NnLuS3Ycaau?= =?us-ascii?Q?Ho9xhdRnqaC/QK//EE3wRLsoRxWJ5OtVdGkdlmAlQNSgBA81nOsHqxkeRlYb?= =?us-ascii?Q?ihDBo/GNzWRrByD/VuVUCzZaOkrx8/BZncxDPvGuoG/9Zm6lblwLWveTiQa+?= =?us-ascii?Q?j3r8YSpHVKPABASo4VM0aRbonHm3?= 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)(1800799024)(376014)(366016)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?iEd0lec66bQfrWZtsmrwZjFGdIQ/KjSbVnPd83WdC2+Rw0zMi/g7ux8bmH0d?= =?us-ascii?Q?8LC2vI4jY1YmMhGQZlWk58shNVf81CZjBrXyR228zdJuGndmT4tN+x63/r/c?= =?us-ascii?Q?DnB0saEVKu7WvulB8ynPn22CTdnrqUU2xpMn3mV5YXJ8+k8GQfjhSZakmi0J?= =?us-ascii?Q?+7WZhU8xfFt1UoCbH0POU6+fTe4xVeWEdwMPl6cLfAK0BKTKoC2PuZlHXrp3?= =?us-ascii?Q?5VI5qFrCi24NYgHGPGEIJ5spvIq0a9eNYEWdBneSqcVwTRgHOYkUnaCaoOhQ?= =?us-ascii?Q?TZd2kik6nWBMh9SERlXoHTDH+hmKwqMlC+4pWZGx6SvmLx9IIaX1RvQ5/PjQ?= =?us-ascii?Q?11q31sF8R36xvZt6EDFM1dxjcMAWiuQPycdHOqgJZ8RJVRZKruchI2o2Ip4V?= =?us-ascii?Q?++kW5pCMXJZF/uB7GpBKn9PVltTl6916llT+UkSn8rp/bDn/BYClLVkKjbAe?= =?us-ascii?Q?QNmeqAqmWymEwspFYhsq4D7lomtAelHN+fJM3/WFIgZ2RyoDR29nTzNiNO1y?= =?us-ascii?Q?nimMiV0tjB+SpQOAeT7U8CKEodaYk3mNwRRhEKWLylJfgJ9tThGxnwaacF04?= =?us-ascii?Q?1jzRpWbQ4iVAblfNLz9pYV0+GN7AuuqWehd1WIbU+0X+y2az2j5zO258VNDi?= =?us-ascii?Q?XiojcxzEnAFnzXjzFX8T3eW5tqnfF2TUzdKssJ6vKlKXYcb3e+LXAvsfgHm1?= =?us-ascii?Q?88JWfurlafksn/wyjdICbTekAH4s4Mfd4VNsorm/vjk1UuDj6QAV1LRMb8nJ?= =?us-ascii?Q?UKEO63Pawx0NoZ2+tYX05tk6Se9s5OFluSokD6+zpT39oiBd29V8YpwZME9c?= =?us-ascii?Q?+oPpeEQBU2EVXqj/26FeLBc9rjFaY1FL/MUj5xdarSnzblSLi9bNOxe0LD+5?= =?us-ascii?Q?ustcY5XTu0LXuA4RAp7ZIR4Sko4RkdmU0SvW3nZFxbytq8NMiElIC1mvsvEN?= =?us-ascii?Q?XDURCtfAh40Aw2F1uS5ihOTbsCzTH8NQisbuE+ukv4xMCOvFHgUd9CARN2yj?= =?us-ascii?Q?Obd1KS56UUp2y0wXPvQox26PUSKDu73jOcGPqxXWb2SuY/8I+pDrXjkcZo0X?= =?us-ascii?Q?ts7vdajLBNFbGDgzpAoiwktvAGJOBl9Kn3cfZTDQa7LYHpjMG5JC3pXJrebD?= =?us-ascii?Q?ynhOj9R9+WH2ep8755Cl0s6RVLJM3anR9vDuUz/oulrNDOaOrDM7OsySIyPn?= =?us-ascii?Q?xSLhE3sJhv5CREl6oARNlaNNWLTFZQieVZmJXrNfrDHYB4/MobdLydjUANZs?= =?us-ascii?Q?TilORwp3UUenpN0sh/hMOiBqmmyrWevEDNAU5yK839B/7/lQPlRqHmY2L/cG?= =?us-ascii?Q?Dn5QRCbf78udHquhmMkXKNTvHes+jGK3xsJOTzk9WNZ+N19nSrlXTNo7cyVe?= =?us-ascii?Q?bgd5KvRx83+EqMNNjP7Ta8RsWj8/D0ufMXT+9l3eEFTGAmeBZSgCkyl8cem8?= =?us-ascii?Q?b+Rhw3GZemy7lCzm7wvfijSTRZUx2PMLHGGKCIWn4EFAr0WKkfFfqCM28lhy?= =?us-ascii?Q?k8vGUC+CBKCeWOIw/Sb7Wv6wpqSV4+31gp3fMAW0O3ltCIqbUuiFkJP78BzT?= =?us-ascii?Q?U14idkPwfoRLNXfEJPhxUbnUg1K/mfnqYckAU114gnYhuwpXaM83LmSGxjo0?= =?us-ascii?Q?+g=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: fe1e4f8f-7800-4f09-729a-08dd46bb4229 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2025 14:33:43.9225 (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: EBebgu7+z2Xm1rSYeBBPAoLqgiE5g0qoCJBNK6X8LnWzrgF06L4s9wfsmUP9uFapxN1zHKbzUtfcK3Y5KnUcUo1LtbLIxizqj3H238Jy/DM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6523 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, Thank you for the review. Please see my comments to your feedback below. > -----Original Message----- > From: Thiago Jung Bauermann > Sent: Thursday, February 6, 2025 4:14 AM > To: Schimpe, Christina > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH 06/12] gdb, gdbserver: Add support of Intel shadow st= ack > pointer register. > = > = > "Schimpe, Christina" writes: > = > > This patch adds the user mode register PL3_SSP which is part of the > > Intel(R) Control-Flow Enforcement Technology (CET) feature for support > > of shadow stack. > > For now, only native and remote debugging support for shadow stack > > userspace on amd64 linux are covered by this patch including 64 bit > > and > > x32 support. 32 bit support is not covered due to missing linux > > kernel > = > Nit: Linux (uppercase l) > = > > support. Will fix. = > > = > > diff --git a/gdb/arch/i386.c b/gdb/arch/i386.c index > > 4a39028a472..59daaa4c583 100644 > > --- a/gdb/arch/i386.c > > +++ b/gdb/arch/i386.c > > @@ -28,6 +28,7 @@ > > #include "../features/i386/32bit-avx512.c" > > #include "../features/i386/32bit-segments.c" > > #include "../features/i386/pkeys.c" > > +#include "../features/i386/32bit-ssp.c" > > > > /* See i386.h. */ > > > > @@ -66,5 +67,8 @@ i386_create_target_description (uint64_t > xstate_bv_mask, bool is_linux, > > if (xstate_bv_mask & X86_XSTATE_PKRU) > > regnum =3D create_feature_i386_pkeys (tdesc.get (), regnum); > > > > + if (xstate_bv_mask & X86_XSTATE_CET_U) > > + regnum =3D create_feature_i386_32bit_ssp (tdesc.get (), regnum); > > + > > return tdesc.release (); > > } > = > The patch description mentions that "32 bit support is not covered due to= missing > linux kernel support". Is this change useful, or is it unreachable code? I think I consistently did not implement 32 bit linux support, but added th= e code for 32 bit support in locations which are not linux dependent, as preparati= on for other OS. But for now yes, this should be unreachable code. Should I (1) Remove the code or (2) improve the commit message ? I'd be in favour of (2), would that be acceptable? > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > > index a86f534528c..fc35456f1d3 100644 > > --- a/gdb/testsuite/lib/gdb.exp > > +++ b/gdb/testsuite/lib/gdb.exp > > @@ -4225,6 +4225,75 @@ gdb_caching_proc allow_tsx_tests {} { > > return $allow_tsx_tests > > } > > > > +# Run a test on the target to check if it supports x86 shadow stack. > > +Return 1 # if shadow stack is enabled, 0 otherwise. > > + > > +gdb_caching_proc allow_ssp_tests {} { > > + global srcdir subdir gdb_prompt hex > > + > > + set me "allow_ssp_tests" > > + > > + if { ![istarget i?86-*-*] && ![istarget x86_64-*-* ] } { > > + verbose "$me: target known to not support shadow stack." > > + return 0 > > + } > > + > > + # There is no need to check the actual HW in addition to ptrace su= pport. > > + # We need both checks and ptrace will tell us about the HW state. > > + set compile_flags "{additional_flags=3D-fcf-protection=3Dreturn}" > > + set src { int main() { return 0; } } > > + if {![gdb_simple_compile $me $src executable $compile_flags]} { > > + return 0 > > + } > > + > > + save_vars { ::env(GLIBC_TUNABLES) } { > > + > > + append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" > > + > > + # No error message, compilation succeeded so now run it via gdb. > > + gdb_exit > > + gdb_start > > + gdb_reinitialize_dir $srcdir/$subdir > > + gdb_load $obj > > + if {![runto_main]} { > > + return 0 > = > There should be a call to "remote_file build delete $obj" here as well. Thanks for catching that. I'll fix it. > > + } > > + set shadow_stack_disabled_re "()" > > + if {[istarget *-*-linux*]} { > > + # Starting with v6.6., the Linux kernel supports CET shadow stack. > > + # Dependent on the target we can see a nullptr or "" > > + # when shadow stack is supported by HW and the linux kernel but > = > Nit: Linux Will fix. > > + # not enabled for the current thread (for example due to a lack > > + # of compiler or glibc support for -fcf-protection). > > + set shadow_stack_disabled_re "$shadow_stack_disabled_re|(.*0x0)" > > + } > = > > = > > diff --git a/gdb/x86-linux-nat.c b/gdb/x86-linux-nat.c index > > d1fece717a7..5bbd4640e30 100644 > > --- a/gdb/x86-linux-nat.c > > +++ b/gdb/x86-linux-nat.c > > @@ -41,6 +41,7 @@ > > #include "nat/x86-linux.h" > > #include "nat/x86-linux-dregs.h" > > #include "nat/linux-ptrace.h" > > +#include "x86-tdep.h" > > #include "nat/x86-linux-tdesc.h" > > > > /* linux_nat_target::low_new_fork implementation. */ @@ -97,11 > > +98,10 @@ const struct target_desc * > > x86_linux_nat_target::read_description () { > > /* The x86_linux_tdesc_for_tid call only reads xcr0 the first time i= t is > > - called. The mask is stored in XSTATE_BV_STORAGE and reused on > > - subsequent calls. Note that GDB currently supports features for = user > > - state components only. However, once supervisor state components= are > > - supported in GDB XSTATE_BV_STORAGE will not be configured based on > > - xcr0 only. */ > > + called. Also it checks the enablement state of features which are > > + not configured in xcr0, such as CET shadow stack. Once the > > + supported > = > The "not" above should be removed. You mean the "not" in this sentence? "Also it checks the enablement state of features which are not configured i= n xcr0, such as CET shadow stack. " This should be correct in that context. CET shadow stack is not configured = in xcr0. > > + features are identified, the XSTATE_BV_STORAGE value is configured > > + accordingly and preserved for subsequent calls of this function. > > + */ > > static uint64_t xstate_bv_storage; > > > > if (inferior_ptid =3D=3D null_ptid) > > @@ -215,6 +215,46 @@ x86_linux_get_thread_area (pid_t pid, void *addr, > > unsigned int *base_addr) } > > > = > = > > > > +/* See x86-linux-nat.h. */ > > + > > +void > > +x86_linux_fetch_ssp (regcache *regcache, const int tid) { > > + uint64_t ssp =3D 0x0; > > + iovec iov {&ssp, sizeof (ssp)}; > > + > > + /* The shadow stack may be enabled and disabled at runtime. Reading= the > > + ssp might fail as shadow stack was not activated for the current > > + thread. We don't want to show a warning but silently return. The > > + register will be shown as unavailable for the user. */ if > > + (ptrace (PTRACE_GETREGSET, tid, NT_X86_SHSTK, &iov) !=3D 0) > > + return; > = > In case the ptrace fails and there is already an old value for ssp in reg= cache, > shouldn't it be removed from it? Hm, it doesn't seem to be a problem. I ran a test using inline enablement o= f shadow stack: ~~~ (gdb) p $pl3_ssp $1 =3D (void *) 0x7ffff7c00000 (gdb) n 54 if (ARCH_PRCTL(ARCH_SHSTK_DISABLE, ARCH_SHSTK_SHSTK)) { (gdb) n 58 return ret; (gdb) p $pl3_ssp $2 =3D ~~~ So it should be fine from my perspective. Or do you see another potential i= ssue? > > + > > + x86_supply_ssp (regcache, ssp); > > +} > > + > > +/* See x86-linux-nat.h. */ > > + > > +void > > +x86_linux_store_ssp (const regcache *regcache, const int tid) { > > + uint64_t ssp =3D 0x0; > > + iovec iov {&ssp, sizeof (ssp)}; > > + x86_collect_ssp (regcache, ssp); > > + > > + /* Starting with v6.6., the Linux kernel supports CET shadow stack. > > + Dependent on the target the ssp register can be unavailable or > > + nullptr when shadow stack is supported by HW and the linux > > + kernel but > = > Nit: Linux Will fix. > > + not enabled for the current thread. In case of nullptr, GDB trie= s to > > + restore the shadow stack pointer after an inferior call. The ptr= ace > > + call with PTRACE_SETREGSET will fail here with errno ENODEV. We > > + don't want to throw an error in this case but silently continue. > > + */ errno =3D 0; if ((ptrace (PTRACE_SETREGSET, tid, NT_X86_SHSTK, > > + &iov) !=3D 0) > > + && (errno !=3D ENODEV)) > > + perror_with_name (_("Failed to write pl3_ssp register")); > = > Same question here: if the ptrace call fails shouldn't the ssp value in r= egcache be > removed? Please see my answer above. > > +} > > + > > void _initialize_x86_linux_nat (); > > void > > _initialize_x86_linux_nat () > > diff --git a/gdb/x86-linux-nat.h b/gdb/x86-linux-nat.h index > > 3c2241bb0b6..d5dc1908090 100644 > > --- a/gdb/x86-linux-nat.h > > +++ b/gdb/x86-linux-nat.h > > @@ -92,4 +92,15 @@ struct x86_linux_nat_target : public > > x86_nat_target extern ps_err_e x86_linux_get_thread_= area > (pid_t pid, void *addr, > > unsigned int *base_addr); > > > > +/* Fetch the value of the shadow stack pointer register from process/t= hread > > + TID and store it to GDB's register cache. */ > > + > > +extern void x86_linux_fetch_ssp (regcache *regcache, const int tid); > > + > > +/* Read the value of the shadow stack pointer from GDB's register cache > > + and store it in the shadow stack pointer register of process/thread= TID. > > + Throw an error in case of failure. */ > > + > > +extern void x86_linux_store_ssp (const regcache *regcache, const int > > +tid); > > + > > #endif /* GDB_X86_LINUX_NAT_H */ > > diff --git a/gdb/x86-tdep.c b/gdb/x86-tdep.c index > > e50b5fb9fa4..08fb0e8d82d 100644 > > --- a/gdb/x86-tdep.c > > +++ b/gdb/x86-tdep.c > > @@ -17,10 +17,32 @@ > > You should have received a copy of the GNU General Public License > > along with this program. If not, see > > . */ > > > > +#include "defs.h" > = > defs.h is now included in all GDB files via the gcc command line, and sho= uldn't be > #included anymore. See commit 18d2988e5da8 ("gdb, gdbserver, gdbsupport: > remove includes of early headers") and commit ab7daea3ad0d ("gdb, gdbserv= er, > gdbsupport: include early header files with `-include`"). Will fix, thanks for pointing that out. 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