From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yMclDnnagGgbizoAWB0awg (envelope-from ) for ; Wed, 23 Jul 2025 08:50:01 -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=NZ9hKKa1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 328A81E11C; Wed, 23 Jul 2025 08:50:01 -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, HTML_MESSAGE,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 AF9C61E0C2 for ; Wed, 23 Jul 2025 08:49:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4EA2F3858C31 for ; Wed, 23 Jul 2025 12:49:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4EA2F3858C31 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=NZ9hKKa1 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by sourceware.org (Postfix) with ESMTPS id E0E1D3858406 for ; Wed, 23 Jul 2025 12:48:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E0E1D3858406 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 E0E1D3858406 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.21 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1753274937; cv=fail; b=lStRAAufBRRMVR3YadbglYj2qKHXJCGk51SIYqgbf+bz3FT+kqRX/ukvjunFEIhqt39W6zBwO6MSzKITuJ7RXbvSpigv3KcESErPA+zmkg149xYjnE5TUARvK5Vs2kDUNqRKILvp/wNuUWoNKvh8VS57Sco0mtouYJzf8YhPsL0= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1753274937; c=relaxed/simple; bh=Fgcd8voP/M2DER3y+1TPZZVRtBwwPTIenPzoc4LiehY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=FkglkkjEerLDm25/w6rmqf92BucorB2L2/vTPPjHPcY1iczfget6w9hP/U8JDv54RIIKGjXOoQY0vmkK0ODp4k/CImC1pJNs9ixJLSIRU18JfkaaCEbOhzYBw4C50XoVMhBCFVi2LOKKmt60KVGzV7v2xwDnWh1nx/NkMaw0DiA= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E0E1D3858406 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1753274938; x=1784810938; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fgcd8voP/M2DER3y+1TPZZVRtBwwPTIenPzoc4LiehY=; b=NZ9hKKa1V+K+1m8hADgThpB141CpAWtUSNhgz/pla5w2I14w3ABqqc1K noQO51qoUuFRLcHlx5LByloC/xXG0ow4O9kZkBTzGopQ8WhjTe+Suuo8O Ob9j49RHZvC/JzrQRrbvu6AAGF6vrvTw9eETdEvBToQ9bNBfVw/ud2HSb hU0FwH3raookHw0Qk/kIT8ZJNe4/OWYMg5x8TfWpd9u0JY3C0z6SzBx7N Xz+fgiRtvuudQmfAn9WxNGvqVEINCSbetpRePJokT4fJwiJznoBrLtGFl EJ5+4haptfUe/m53ZifxVTwwwvojSivNAm3TNbXxmV1RNAtcZnhhiq99Z A==; X-CSE-ConnectionGUID: bF53xTfJS3+ZDfRUxgQ2HQ== X-CSE-MsgGUID: slalZWzETMS8cBfeiOZ/qg== X-IronPort-AV: E=McAfee;i="6800,10657,11501"; a="55432777" X-IronPort-AV: E=Sophos;i="6.16,333,1744095600"; d="scan'208,217";a="55432777" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2025 05:48:05 -0700 X-CSE-ConnectionGUID: yWkW+gYSQLS34DKqYFTBdQ== X-CSE-MsgGUID: XRbL2QCNTtCELL9He2PT6g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,333,1744095600"; d="scan'208,217";a="163744426" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa005.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2025 05:48:02 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) 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; Wed, 23 Jul 2025 05:48:02 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26 via Frontend Transport; Wed, 23 Jul 2025 05:48:02 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (40.107.220.54) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.25; Wed, 23 Jul 2025 05:48:01 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ESDaxPMJkbi2MgYq8MjBi/gc2Gj8O3vThRcSgpm/FLCudpqGykYXYS1lvh7EhXgqwHTEFojsGu+OsQWfQ8YRARoIRuuFu27OZRIrNkNKxsS0KV1SfiDnXrWWQeM+9aY1qvgVCYodtTF7C0VaL0quAjE947FjWTqRspgbbhtRc+9X3vIrT3wtp5sxbw1eOl6mmc60vDJhAmx8hxlqJk4f5KI7zM9BpaPl/e9Vd7CaMnZJW2xl3+apNaLgryt1M7jbJWg2HMlwSx7kpgyq6RFJ0OMzeQdQUWaJDDY7NOOG4bmqm9VdJYDza1Dq/XVFifPEtIBWIo3u0S8h6X9GoYdCgQ== 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=LJ1zX0MTnjOnv1sgyZRJGzDMOB47dxbZK/UDxbHGs3c=; b=ReWwXqiOKyK+gHJVIMwamweLc8cshiKmjGuQT4g48Un8GbO14Hbx9NHIMSdsEi0mjfRSlRfa3g0T4+12UM3mtbq+h8bJczl+4Q89vnpcA3iHus+j2sb6Fasw3zW1Ow/2+H/g7QqTTagC9Iz3thoyHW9uB1lITOUZxiSSCTMZzJUancg1ZqoqpPV2rb27/wX0t2UaY6ed2DFlKIF2sDohsfqRlkQ/ECjh01Mfm169wKYp+RCDYaa2+ARCtApyBfkm+CddvHdA2Sm3lgXUgErBk8AUsKeN2vcNTP7pL/4a7BspvX9D7FKcjtnbRBSo8tlduNdEDVlS3p9y3LiLXsQ54w== 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 PH8PR11MB6681.namprd11.prod.outlook.com (2603:10b6:510:1c4::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8964.22; Wed, 23 Jul 2025 12:47:59 +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.8943.024; Wed, 23 Jul 2025 12:47:59 +0000 From: "Schimpe, Christina" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: "thiago.bauermann@linaro.org" , "luis.machado@arm.com" Subject: RE: [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for target description creation on x86. Thread-Topic: [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for target description creation on x86. Thread-Index: AQHb6Ae6sAA/elE6MEGpsLX+dkyqXrQxvOMAgAEZDIOADPmUoA== Date: Wed, 23 Jul 2025 12:47:59 +0000 Message-ID: References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-6-christina.schimpe@intel.com> <8734aynam5.fsf@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: 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_|PH8PR11MB6681:EE_ x-ms-office365-filtering-correlation-id: 3c6795ab-ac54-4db7-1e2e-08ddc9e727ad x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|376014|1800799024|8096899003|7053199007|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?kGXCXWFZfWjKwpOHSmFv/RDzvxZ6RyQLSo3ULbP0g2ndIBmB6uigu0SUFJIU?= =?us-ascii?Q?pyITiks/Ar+q4IlMyg1n1I7fXJyfiHHJhzgU4SQ5gMJhyKrZkpVMC0UH37nl?= =?us-ascii?Q?082c2rvdnSnrB2ua5FZK+S3zCep7OfJtHZF4F/1qyjlzOmElR8+rMjSWdTzm?= =?us-ascii?Q?3jS8gnRE0MUNgdelHZXcY9Wq5YGrxV5IsKRM9OYbq7Boh/oTJJyoAUF7NM2o?= =?us-ascii?Q?I1kYDZLDk1EjL4EGofhvnGDgyAM7l0iESw3XRiICkN26GnTewwMGbIhrsAWo?= =?us-ascii?Q?PmH9agWiusOSvbGNAw906TUdrPavGyxf3GxLovlndIlHUF76lsq/fMeyk383?= =?us-ascii?Q?y3HYjPYNU24fTiTceLgwgdzirXlK2ea1Y0/Qiwr1pYTMLYtaYfzZ4aMEZ5go?= =?us-ascii?Q?qF7FongwOyleuEm6nXLKLxv3t4bGGopXO+t2PtqG4EODLwcVG0CH8arHzTb4?= =?us-ascii?Q?fECTHWmRowU2gJHZci6dAyJGcl0FDtXLMdmL0zUbK+AjlsoGZVHs8dxbd+rW?= =?us-ascii?Q?NGysk0SVKv6t8RI4sh9St2KIBIUYoOurGP0eY+0UbDpAC/Zk/w/8oD6JWM+0?= =?us-ascii?Q?C1dnCpNgoTJ0wf84opA6F2JgzBqUUDKEv8216Hd84kE6XOlzky14SQ5dQRcI?= =?us-ascii?Q?YUrfP2GxE8aT6BJvC/re04LeiQ6CjY93oUAjAf4sjtC0rZ6tBLZtHWbLr3xo?= =?us-ascii?Q?MfwtpvgqdEUPiFCqu5gmdjtCRqZB+jWKtJFsNbSk6Bz8+jAemWlaAdQUHtvW?= =?us-ascii?Q?lFoZmfpjMbLv/3VegTbWdQpwRAJLDh60gnuAM81Ub8y5xwYsI8ztWIe2QRHm?= =?us-ascii?Q?f38obu2Lb9ik0EB5v4JOMB/d4Xfzg/nEJQI6A0IVMRBQnFWtXABKjT+vVsAX?= =?us-ascii?Q?qnuBZmMKWIc5EejIU5YscQrvwxVU5q9sQQIitJgf9W2ug6gtUkfsbfE8GAOb?= =?us-ascii?Q?hI2PMVbrZVUu7gDH1mLfV5xrYz6OUIVxAkbpW80c+ztb4Ac8sLBhMlSi/6FP?= =?us-ascii?Q?9QhTe8MUQOjg1cwQaHzOum6bo8N+OrwRLOYriCbH5t+mZsUxHJhJKIlz2B6g?= =?us-ascii?Q?8pmXuqFTjZZ0or8o1yOoA7FOXm0lMb2YFSzRTomEDnaH3LAfDAuUxo+W1+TN?= =?us-ascii?Q?y5F1zymDT3tlELSRinfJSNX4DSSaZw3QCXlvOCEe1vExJD9CQta0N5mxW7zc?= =?us-ascii?Q?GjPHyYp7ap/oglqsx/Ts9B6XfLAZVpwq27KHbdrEwBVCP1wOWmo4uugz//le?= =?us-ascii?Q?fw3Pv6O7ha1Z2WlzL8ERReHHAR7WVgthQ5ol7gC5lSVSWPQVMvaBVXiNP761?= =?us-ascii?Q?y+8CwsTFWLsiLPX51g9Ew4pASMrLmC0AnG/h3aLABF2dRvCRz6oIhEQzHMSR?= =?us-ascii?Q?Ke0MjbUfJ8XzSsI81X8NAdwhMoQeLfn4J8aUnKGxNIXC1fDEIeNwzKBxTAur?= =?us-ascii?Q?hXb1D4sBA4SqEDYKziykT7Q9LVyqqG+IKXA4p+AoMY+5tHrHT+0whw=3D=3D?= 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)(376014)(1800799024)(8096899003)(7053199007)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?93ipmCP/9D77RQQ6haNS6MWGrJzMDk4KfNra+6OSfPXzjn03j3e4o5P9UNr2?= =?us-ascii?Q?es/feOBjHo8yCXgkr4ZXLqRO3rH7nawt2InMHE1Rs9iftPKQ3fpCaF/2wIeg?= =?us-ascii?Q?MZqMCWDBKy4DmdfhMqzSkvsZYQmsR0m6tjMrGoDBT/j/OcAwb94KtrjUkHHW?= =?us-ascii?Q?F6GHbJNo9YBnEatEcYrsamW9kSMQzOfhI8F0zMRiYt5bH5WZlvUaQfP5ocHE?= =?us-ascii?Q?FynKY+U/tzthM+0XrW8K8B6v+iPTwhHiYFe7ztpdkpa/7UKSqJFFIFyHKovR?= =?us-ascii?Q?POFQ5Mae+oe+AYbKtjAS7fezk+w+J1XY+uleBc56RkHvsURFm/6G9n3L7d9R?= =?us-ascii?Q?p8ti6PMMXVOOg5S+uagOhumrJwch3tV5PHDEA9dHSpx+a2UEGUwyfTiN5ZW4?= =?us-ascii?Q?Do3M31X8oP8dLUsCfQOqADRfDD4zaCa2zVpgAzvzksCbREF+YBtcp7U9sMjG?= =?us-ascii?Q?bktwgMZJ2QyHvbbi4P7TuKbAarUOA7CFuFELjjhYCKINmGFEm8QcLpxeSPyY?= =?us-ascii?Q?bcKjNn1uWcQPwc1IKtStfY8Xe4iIJWoaPldpbSXXGVZDn1ELfgaDUjif7q+6?= =?us-ascii?Q?zwrKr0LJi5L9XPFwgyXe9tcwu21V8ZUR3BiABdYn2zgidGDdXZPn/grAIM8j?= =?us-ascii?Q?yXQ3b9SFmFT7ptSKRjLyyeuj7bKx9PMvbaIRgGHNj2AV9ERuodDcuLQ5dYyQ?= =?us-ascii?Q?gV4B3a5hiiXVXJ7/Sza9uGvoE1CrL5q2TxXWA7pnwQuH0A/wmY5kgl/VQzWz?= =?us-ascii?Q?wGZxNwMwMRmY3QOge0YvnrKfJUcwHKclqyCUhXfD6eHrti0Uzd1sIHVWBbd1?= =?us-ascii?Q?HZBZddLkf+hah2Feii/+adu4xh3cBH2os7l0Pn781+cloxUwn9ucuITYWK4c?= =?us-ascii?Q?w80AtIntYggK+aTKFBqK8AO0g1jDnO7DaT4wqI6MiROvjYImPrNb2tJvg7mS?= =?us-ascii?Q?wdWbiYku9Cs+TgxgR8bStum6r7lgJZyVujQ8IkjXBTq0WUYh6ECxvjZGrPSi?= =?us-ascii?Q?zpkw+MapMilloWksysPqHRiJHAVobwBbYx0DQ2FdoKGpoZ+Hpnf8KVmaeD7z?= =?us-ascii?Q?A8yXBMTo8/IDBRj0B5zDbYb3kc46ycJyJJx9aMbnweoajvhm8UrOFtAKPdqS?= =?us-ascii?Q?uNFRFxKj37DWLweq6UCk9x9wUU8bW6Ma6H/0tTgm0WpmEl4uI/5Y0IF5yoCP?= =?us-ascii?Q?SSo9K/M73wXvoU21i1BmPkaH5IdE61AfS4W8XfjeWK90Xzo//NIcqM8GOdPa?= =?us-ascii?Q?kOHTbv7LVVm1B04+mPwjOW0fgwkymFPi/wKRQJ3S/TMi54ecLrYuoIwEBTwn?= =?us-ascii?Q?jCuLCcZEuGjViJmHYqjDS7o9VHIQouTuzqQ0IdkJM+7djaf57GankBU5iWdI?= =?us-ascii?Q?T3TfgsaVA/4m3Th7hYpjVFHKMtm7WxCruljHFgLE/NTLJ5omm6mhR8D9mX6X?= =?us-ascii?Q?xZWK1Kd7Dqxk+Tg859DLbsvuUTepxo9yOQ3kr9MHlJOi7rFSgG9+ms/Klb5j?= =?us-ascii?Q?o3x6G9S+2IlBp8ZbCv6RNnc05d2EoY8vTwCpC35LhkQLFYbyHOXLSge7tfwY?= =?us-ascii?Q?alxUJj/w2hI/NARv8w28jYLQZrgAqoWcK8sSoObW4PkmJ5Au7pyFGk0PNq8q?= =?us-ascii?Q?xg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SN7PR11MB7638F3C7ACEB62AB9FFE30BDF95FASN7PR11MB7638namp_" 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: 3c6795ab-ac54-4db7-1e2e-08ddc9e727ad X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2025 12:47:59.6420 (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: sYV1kZvyb/eyDEU3X/hgc+WQAvorlM4rKKO8WR9nA+SYueioPgChg2xo/zoBi5kCiO1hzZAFloEdyq5WY8qoUs8W7hczp9N9WMcylKrKzbI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6681 X-OriginatorOrg: intel.com 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 --_000_SN7PR11MB7638F3C7ACEB62AB9FFE30BDF95FASN7PR11MB7638namp_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Andrew, Do you have any final comments ? My plan would be to fix your comments locally (as described below) and push= the series by tomorrow. Or should I repost this patch to be sure? Thanks, Christina From: Schimpe, Christina Sent: Tuesday, July 15, 2025 12:28 PM To: Andrew Burgess ; gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org; luis.machado@arm.com Subject: Re: [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for target desc= ription creation on x86. Hi Andrew, Thanks a lot for the review. >> The XSAVE features set is organized in state components, which are a set >> of or parts of registers. So-called XSAVE-supported features are > Maybe here you mean: "..., which are a set of, or parts of, registers." > If not, then this sentence doesn't make sense to me I agree, this sentence is a bit confusing. I think I would prefer to write = it out actually. Is the following more understandable? "The XSAVE function set is organized in state components, which are a set o= f registers or parts of registers." >> The SDM uses the term xstate_bv for a state-component bitmap, which is > Would it be possible to define what SDM it please. Do you mean writing it out to "Intel Software Developer's Manual" ? > I'd like to ask about the use of 'mask' in this variable name. We used > to pass in an xcr0 value, which was then combined with various masks to > extract the state bits we were interested in. > You've renamed the new variable as a mask, but continue to combine it > with the same masks (e.g. X86_XSTATE_AVX), which makes me suspect the > variable is not a mask at all. It's not a mask at all. I honestly cannot tell why I decided to call this x= state_bv instead of xstate_bv_mask when I wrote this patch... > Now, I can see where the confusion might have come from. Almost every > call to amd64_target_description passes in a *_MASK constant. But > that's OK, given these are bit sets, then the MASK constants actually > define valid values. > I am aware that this sounds like a trivial complaint over a variable > name, but I think calling this a mask is pretty confusing (at least to > me), so unless I'm not understanding this, then I think it is worth > renaming this. > The use of `mask` for the value is present throughout this patch, not > just this one function. I agree and am glad for your feedback here. The current naming is confusing and I will rename it to xstate_bv. Christina ________________________________ From: Andrew Burgess > Sent: Monday, July 14, 2025 3:52 PM To: Schimpe, Christina >; gdb-patches@sourceware.org > Cc: thiago.bauermann@linaro.org >; luis.machado@ar= m.com > Subject: Re: [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for target desc= ription creation on x86. Christina Schimpe > writes: > The XSAVE features set is organized in state components, which are a set > of or parts of registers. So-called XSAVE-supported features are Maybe here you mean: "..., which are a set of, or parts of, registers." If not, then this sentence doesn't make sense to me. > organized using state-component bitmaps, each bit corresponding to a > single state component. > > The SDM uses the term xstate_bv for a state-component bitmap, which is Would it be possible to define what SDM it please. > defined as XCR0 | IA32_XSS. The control register XCR0 only contains a > state-component bitmap that specifies user state components, while IA32_X= SS > contains a state-component bitmap that specifies supervisor state compone= nts. > > Until now, XCR0 is used as input for target description creation in GDB. > However, a following patch will add userspace support for the CET shadow > stack feature by Intel. The CET state is configured in IA32_XSS and cons= ists > of 2 state components: > - State component 11 used for the 2 MSRs controlling user-mode > functionality for CET (CET_U state) > - State component 12 used for the 3 MSRs containing shadow-stack pointers > for privilege levels 0-2 (CET_S state). > > Reading the CET shadow stack pointer register on linux requires a separate > ptrace call using NT_X86_SHSTK. To pass the CET shadow stack enablement > state we would like to pass the xstate_bv value instead of xcr0 for target > description creation. To prepare for that, we rename the xcr0 mask > values for target description creation to xstate_bv. However, this > patch doesn't add any functional changes in GDB. > > Future states specified in IA32_XSS such as CET will create a combined > xstate_bv_mask including xcr0 register value and its corresponding bit in > the state component bitmap. This combined mask will then be used to crea= te > the target descriptions. > > Reviewed-by: Thiago Jung Bauermann > > Reviewed-By: Luis Machado > > --- > gdb/amd64-tdep.c | 14 +++---- > gdb/amd64-tdep.h | 8 +++- > gdb/arch/amd64-linux-tdesc.c | 33 ++++++++-------- > gdb/arch/amd64-linux-tdesc.h | 7 ++-- > gdb/arch/amd64.c | 15 +++----- > gdb/arch/amd64.h | 10 ++++- > gdb/arch/i386-linux-tdesc.c | 29 +++++++------- > gdb/arch/i386-linux-tdesc.h | 5 ++- > gdb/arch/i386.c | 15 ++++---- > gdb/arch/i386.h | 8 +++- > gdb/arch/x86-linux-tdesc-features.c | 59 +++++++++++++++-------------- > gdb/arch/x86-linux-tdesc-features.h | 25 +++++++----- > gdb/i386-tdep.c | 14 +++---- > gdb/i386-tdep.h | 7 +++- > gdb/nat/x86-linux-tdesc.c | 18 +++++---- > gdb/nat/x86-linux-tdesc.h | 7 ++-- > gdb/x86-linux-nat.c | 11 ++++-- > gdbserver/i387-fp.cc | 40 +++++++++---------- > gdbserver/linux-amd64-ipa.cc | 10 +++-- > gdbserver/linux-i386-ipa.cc | 6 +-- > gdbserver/linux-x86-low.cc | 9 ++--- > gdbsupport/x86-xstate.h | 4 +- > 22 files changed, 198 insertions(+), 156 deletions(-) > > diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c > index 82dd1e07cf3..04539dd288a 100644 > --- a/gdb/amd64-tdep.c > +++ b/gdb/amd64-tdep.c > @@ -3551,23 +3551,23 @@ amd64_x32_none_init_abi (gdbarch_info info, gdbar= ch *arch) > amd64_target_description (X86_XSTATE_SSE_MASK, true)= ); > } > > -/* Return the target description for a specified XSAVE feature mask. */ > +/* See amd64-tdep.h. */ > > const struct target_desc * > -amd64_target_description (uint64_t xcr0, bool segments) > +amd64_target_description (uint64_t xstate_bv_mask, bool segments) I'd like to ask about the use of 'mask' in this variable name. We used to pass in an xcr0 value, which was then combined with various masks to extract the state bits we were interested in. You've renamed the new variable as a mask, but continue to combine it with the same masks (e.g. X86_XSTATE_AVX), which makes me suspect the variable is not a mask at all. Now, I can see where the confusion might have come from. Almost every call to amd64_target_description passes in a *_MASK constant. But that's OK, given these are bit sets, then the MASK constants actually define valid values. I am aware that this sounds like a trivial complaint over a variable name, but I think calling this a mask is pretty confusing (at least to me), so unless I'm not understanding this, then I think it is worth renaming this. The use of `mask` for the value is present throughout this patch, not just this one function. Thanks, Andrew 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 --_000_SN7PR11MB7638F3C7ACEB62AB9FFE30BDF95FASN7PR11MB7638namp_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

Do you have any final comments ?

My plan would be to fix your comments locally (as described below) = and push the series by tomorrow.

Or should I repost this patch to be sure?

 

Thanks,

Christina

 

From: = Schimpe, Christina <christina.schimpe@intel.com>
Sent: Tuesday, July 15, 2025 12:28 PM
To: Andrew Burgess <aburgess@redhat.com>; gdb-patches@sourcewa= re.org
Cc: thiago.bauermann@linaro.org; luis.machado@arm.com
Subject: Re: [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for targ= et description creation on x86.

 

Hi Andrew, 

 =

Thanks a lot for the rev= iew. 

 =

>> The XSAVE featu= res set is organized in state components, which are a set
>> of or parts of registers.  So-called XSAVE-supported features= are

> Maybe here you mean: "..., which are a set of, or parts of, regis= ters."
> If not, then this sentence doesn't make sense to me<= /p>

 =

I agree, this sentence i= s a bit confusing. I think I would prefer to write it out actually.

Is the following more un= derstandable?

"The XSAVE function= set is organized in state components, which are a set of registers

or parts of registers.&q= uot;

 =

>> The SDM uses th= e term xstate_bv for a state-component bitmap, which is

> Would it be possible to define what SDM it please.

 =

Do you mean writing it o= ut to "Intel Software Developer’s Manual" ?

 =

> I'd like to ask abo= ut the use of 'mask' in this variable name.  We used
> to pass in an xcr0 value, which was then combined with various masks t= o
> extract the state bits we were interested in.

> You've renamed the new variable as a mask, but continue to combine it<= br> > with the same masks (e.g. X86_XSTATE_AVX), which makes me suspect the<= br> > variable is not a mask at all.

 =

It's not a mask at all. = I honestly cannot tell why I decided to call this xstate_bv

instead of xstate_bv_mas= k when I wrote this patch...

> Now, I can see where the confusion might have come from.  Al= most every
> call to amd64_target_description passes in a *_MASK constant.&nbs= p; But
> that's OK, given these are bit sets, then the MASK constants actu= ally
> define valid values.

> I am aware that this sounds like a trivial complaint over a varia= ble
> name, but I think calling this a mask is pretty confusing (at lea= st to
> me), so unless I'm not understanding this, then I think it is wor= th
> renaming this.

> The use of `mask` for the value is present throughout this patch,= not
> just this one function.

 =

I agree and am glad for = your feedback here.

The current naming is co= nfusing and I will rename it to xstate_bv.

 =

Christina

 =

From: A= ndrew Burgess <aburgess@redhat.co= m>
Sent: Monday, July 14, 2025 3:52 PM
To: Schimpe, Christina <christina.schimpe@intel.com>; gdb-patches@sourceware.org <gdb-patches@sourceware.= org>
Cc: thiago.bauer= mann@linaro.org <thia= go.bauermann@linaro.org>; luis.machado@arm.com <luis.machado@arm.com>
Subject: Re: [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for= target description creation on x86.

 

Christina Schimpe <christina.schimpe@intel.com> writes:

> The XSAVE features set is organized in state components, which are a s= et
> of or parts of registers.  So-called XSAVE-supported features are=

Maybe here you mean: "..., which are a set of, or parts of, registers.= "
If not, then this sentence doesn't make sense to me.

> organized using state-component bitmaps, each bit corresponding to a > single state component.
>
> The SDM uses the term xstate_bv for a state-component bitmap, which is=

Would it be possible to define what SDM it please.

> defined as XCR0 | IA32_XSS.  The control register XCR0 only conta= ins a
> state-component bitmap that specifies user state components, while IA3= 2_XSS
> contains a state-component bitmap that specifies supervisor state comp= onents.
>
> Until now, XCR0 is used as input for target description creation in GD= B.
> However, a following patch will add userspace support for the CET shad= ow
> stack feature by Intel.  The CET state is configured in IA32_XSS = and consists
> of 2 state components:
> - State component 11 used for the 2 MSRs controlling user-mode
>   functionality for CET (CET_U state)
> - State component 12 used for the 3 MSRs containing shadow-stack point= ers
>   for privilege levels 0-2 (CET_S state).
>
> Reading the CET shadow stack pointer register on linux requires a sepa= rate
> ptrace call using NT_X86_SHSTK.  To pass the CET shadow stack ena= blement
> state we would like to pass the xstate_bv value instead of xcr0 for ta= rget
> description creation.  To prepare for that, we rename the xcr0 ma= sk
> values for target description creation to xstate_bv.  However, th= is
> patch doesn't add any functional changes in GDB.
>
> Future states specified in IA32_XSS such as CET will create a combined=
> xstate_bv_mask including xcr0 register value and its corresponding bit= in
> the state component bitmap.  This combined mask will then be used= to create
> the target descriptions.
>
> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> Reviewed-By: Luis Machado <= luis.machado@arm.com>
> ---
>  gdb/amd64-tdep.c        =             | 14 +++= ----
>  gdb/amd64-tdep.h        =             |  = 8 +++-
>  gdb/arch/amd64-linux-tdesc.c      =   | 33 ++++++++--------
>  gdb/arch/amd64-linux-tdesc.h      =   |  7 ++--
>  gdb/arch/amd64.c        =             | 15 +++= -----
>  gdb/arch/amd64.h        =             | 10 +++= +-
>  gdb/arch/i386-linux-tdesc.c      &= nbsp;  | 29 +++++++-------
>  gdb/arch/i386-linux-tdesc.h      &= nbsp;  |  5 ++-
>  gdb/arch/i386.c        &= nbsp;            | 1= 5 ++++----
>  gdb/arch/i386.h        &= nbsp;            |&n= bsp; 8 +++-
>  gdb/arch/x86-linux-tdesc-features.c | 59 +++++++++++++++--------= ------
>  gdb/arch/x86-linux-tdesc-features.h | 25 +++++++-----
>  gdb/i386-tdep.c        &= nbsp;            | 1= 4 +++----
>  gdb/i386-tdep.h        &= nbsp;            |&n= bsp; 7 +++-
>  gdb/nat/x86-linux-tdesc.c      &nb= sp;    | 18 +++++----
>  gdb/nat/x86-linux-tdesc.h      &nb= sp;    |  7 ++--
>  gdb/x86-linux-nat.c       &nb= sp;         | 11 ++++--
>  gdbserver/i387-fp.cc       &n= bsp;        | 40 +++++++++----------
>  gdbserver/linux-amd64-ipa.cc      =   | 10 +++--
>  gdbserver/linux-i386-ipa.cc      &= nbsp;  |  6 +--
>  gdbserver/linux-x86-low.cc      &n= bsp;   |  9 ++---
>  gdbsupport/x86-xstate.h       = ;      |  4 +-
>  22 files changed, 198 insertions(+), 156 deletions(-)
>
> diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
> index 82dd1e07cf3..04539dd288a 100644
> --- a/gdb/amd64-tdep.c
> +++ b/gdb/amd64-tdep.c
> @@ -3551,23 +3551,23 @@ amd64_x32_none_init_abi (gdbarch_info info, gd= barch *arch)
>            = ;          amd64_target_descri= ption (X86_XSTATE_SSE_MASK, true));
>  }
> 
> -/* Return the target description for a specified XSAVE feature mask.&= nbsp; */
> +/* See amd64-tdep.h.  */
> 
>  const struct target_desc *
> -amd64_target_description (uint64_t xcr0, bool segments)
> +amd64_target_description (uint64_t xstate_bv_mask, bool segments)

I'd like to ask about the use of 'mask' in this variable name.  We use= d
to pass in an xcr0 value, which was then combined with various masks to
extract the state bits we were interested in.

You've renamed the new variable as a mask, but continue to combine it
with the same masks (e.g. X86_XSTATE_AVX), which makes me suspect the
variable is not a mask at all.

Now, I can see where the confusion might have come from.  Almost every=
call to amd64_target_description passes in a *_MASK constant.  But
that's OK, given these are bit sets, then the MASK constants actually
define valid values.

I am aware that this sounds like a trivial complaint over a variable
name, but I think calling this a mask is pretty confusing (at least to
me), so unless I'm not understanding this, then I think it is worth
renaming this.

The use of `mask` for the value is present throughout this patch, not
just this one function.

Thanks,
Andrew

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

Chairpers= on of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--_000_SN7PR11MB7638F3C7ACEB62AB9FFE30BDF95FASN7PR11MB7638namp_--