From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id E8MyDZItdmj9cjUAWB0awg (envelope-from ) for ; Tue, 15 Jul 2025 06:29:38 -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=MMwRCtj5; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 265231E11C; Tue, 15 Jul 2025 06:29:38 -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 EEA3D1E0C2 for ; Tue, 15 Jul 2025 06:29:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7C2E23857B90 for ; Tue, 15 Jul 2025 10:29:35 +0000 (GMT) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by sourceware.org (Postfix) with ESMTPS id 69DAA3858D37 for ; Tue, 15 Jul 2025 10:29:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 69DAA3858D37 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 69DAA3858D37 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=192.198.163.18 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1752575352; cv=fail; b=KnD8kYJltKqWkNM3r+fGyTeS8CIWAgziky01+qOCjOE0e++X7TWRZ7yvVXLi74mXiDqWP9i4wX9cAp5mL3ZPGF4ZhOTMzuREB8sSz1OmCPuvVt2b5K+c4mGIOUB+mcNCUI6SSsw+p5LlURX7TMuITSlzzY8yGr/GN7yxH8O7ojs= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1752575352; c=relaxed/simple; bh=zuPe0JyYlbaX2PWwDtl1K0cvyifvvDy8zumh0gH3W1A=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=fvbOmbKMeha2C7djnlpjqp1kNeXs+7bL14mkD/rWw3MaD24Ps/BwTWHzGygeGK3I2hx//tR5Zjx2GnfoUyDsziOM+XWuAkOYyLca3IhCkeza0sQs2SwoyLuJRy1DeqfJHiwHdQLf50ou6FAIK4ra0x/XNa7qr15FZ6obO3mq8qo= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69DAA3858D37 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=MMwRCtj5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752575353; x=1784111353; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zuPe0JyYlbaX2PWwDtl1K0cvyifvvDy8zumh0gH3W1A=; b=MMwRCtj50K17yu/J8MmEryFtnpBt07sYHy8cgf+lObdkqF/mvvudS/SW 9UuDsziuoR+nS3Airku8yNWPXUePJ0lvw0/CHIC5feRAk7mN4xvr9gBZN 6xuxFYBnVhCvvLwrZ50I8iaeZMHTeFsuYl4YpIcsqRAAPkMTBIKead+MN ohGydQevYFFRZ65D8u3K8mxNT1yw/Gl5RAORfSFTyf/KfKfb9UcBY3eTN xsFKyPTYzDy81ed99vFHB6BYtKbftD27bRyJ2hNKFHvTP2MpyHw5wudbw E3f8l0QpU/H4Y5cC0d11wstf/sk/wzTDmof20iaK92XiUmo8l3fZOK69M w==; X-CSE-ConnectionGUID: T27Vx8YhRki5OK1PUlZU1g== X-CSE-MsgGUID: /CFhJl6pQVGWDmm3dAmGOQ== X-IronPort-AV: E=McAfee;i="6800,10657,11491"; a="54008295" X-IronPort-AV: E=Sophos;i="6.16,313,1744095600"; d="scan'208,217";a="54008295" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2025 03:29:11 -0700 X-CSE-ConnectionGUID: bdocXXAPSWeo5V2OXcTIYQ== X-CSE-MsgGUID: qN3ey2S1TsKMQh/OquD5wA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,313,1744095600"; d="scan'208,217";a="157907739" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2025 03:29:10 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) 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; Tue, 15 Jul 2025 03:29:09 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) 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; Tue, 15 Jul 2025 03:29:09 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (40.107.237.56) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Tue, 15 Jul 2025 03:29:07 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uSZWiZgYX88kB71WEN0jDwRSHhzVELxn/P8wEqAj2Y0mVqP+ja03ZQ8PPe9bkQIsNEa9gtYoP0MHyEHkHOf0wuMR9fiXrQz7jeOI+glpkFZSPcQs3/gtWIMkBB7zyblm8IFhr3S/NGKDNAPIhpaXRgxRk2IsLUNqO3dB2zIy1GbBpox+BrJAzKEltmJ7fxTtMRH28AS1W9qA4cwb3Gq50FvaNyru27dY2qXGHB0kzAKSQ7gpyO6Jr+tVWtLoIEDwI+Y+9RsU0m3MswpKnaBIuXpUkucVrz5h7qTFws04oy3/WOvEqpXPTYaWAaNMJwYPw24V/936Ysd2dqs/bo6ANA== 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=q9pLSXDiUOwrRUSpTnNdyuqDqGThvi4XoaB9fA5q85w=; b=WW+SNhfgCb83ghpYMbTkoEAiSwDFFEhy9nf3KgJa3Yq7hoBudWOwM09UQNqdqut1ESOQnzaf25F6ckmlpFhW6QLx7qPsoIfn465Djd0r+sXEbdWYYpnIpXboYtFEk6jEHvjS5I5UiM5wPVwbRTKuLjARGxT7EyVudguOZUWIt/UolIcRiIC4BVKpwmXYOpHOVeFHE96khjuHyU7pV939mtvqoHQbb46OsXtmMEE7AzV5IM0NuTVE35+XCMH9fK8kX7RBIdXL+0HIHicIWyjp5y8wbbdSTBBpxwUgyOPiEocsxhtq+bFhL5qR7euq85IKOpAAuYlSK/YSQu2Hvj8Weg== 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 SN7PR11MB8066.namprd11.prod.outlook.com (2603:10b6:806:2df::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8922.32; Tue, 15 Jul 2025 10:28:24 +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.8857.026; Tue, 15 Jul 2025 10:28:24 +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+dkyqXrQxvOMAgAEZDIM= Date: Tue, 15 Jul 2025 10:28:24 +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: <8734aynam5.fsf@redhat.com> 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_|SN7PR11MB8066:EE_ x-ms-office365-filtering-correlation-id: 4eb5e6f2-3b1b-441a-f816-08ddc38a5468 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|1800799024|376014|8096899003|38070700018; x-microsoft-antispam-message-info: =?Windows-1252?Q?bL5DnjlqjBXc+P9GW4RQ7KefmIW6fNw+76musW1IPrXj6sB559Ma5264?= =?Windows-1252?Q?DKe9ichtxPKlfrYzzaahoV0wKVWZB61SVkbsAFEgMI3ysIpEQRQYNo6H?= =?Windows-1252?Q?NoWzPh0cGp68dns1rtLKkr6YFkeKYqQuSf8odP2r+oXDO65P1NFOmcxt?= =?Windows-1252?Q?hjSV4ikfKY1jq+QncU4Xmau9IVrYDckiIIOSgK7Yn3xLRbKa5+Aw/B5S?= =?Windows-1252?Q?t/m+D67tPB3lJOxaiU2xiYgSws4shxxrH+LU+aRdceNGjIeMRk1iT3md?= =?Windows-1252?Q?PCDC6MyWeAAH06D9SCugiX4BzJZBcS6nvR7LWqE7N0tRIJfcyS2Ep5v1?= =?Windows-1252?Q?Aftkx1zwcTl9oQ1oIsMkuYVPBe6ShsbflYKUwX9aH0zlwPUFJ2yBvIMd?= =?Windows-1252?Q?vurXP89CMfNoX3H5HZa3BsHL87phZMAlTsWHVtjezDJInr+IfjvSOLCb?= =?Windows-1252?Q?8SvvcH4RdG20T4+nM0mPDa7AgFDr/RtQZfwMpLMJLNUZkl5nJslDS01q?= =?Windows-1252?Q?wNbj6ZFF5yQwSa137qGRRaxu1zVj0niPI5NopRPidhUi4hZWRX24n4F8?= =?Windows-1252?Q?B3rKKaEokD/IfltQrMkW68LSUDtVwVZTTefJ2MDGMK821yNEsNik3rJL?= =?Windows-1252?Q?S5kAaA/VLwEGFCeV8T0kiXJfHZurzT1+lSDrnOPCf3jujST60/VWfni2?= =?Windows-1252?Q?EJdtx/GTAkLHXLjg+t6w5O9/5kdfRZh+P9hRUcsLtyyp8JTosgGvhEJf?= =?Windows-1252?Q?7zaTeM0yveG3ehDxGLMUlCuNH1K8X3PH7N2z+KRMfDDupArCRwIwpoqS?= =?Windows-1252?Q?dpsA5eaiMwiwl94vggc8P+DaUQJYmDt/NzU7IoB3VrDE/5oihD3zLfGs?= =?Windows-1252?Q?NC3rrEhHrMr3WLLYAixWCHuLxRsYwntc1GfPrDRQmHXtyDXP6Kb5plfc?= =?Windows-1252?Q?J5d0l8bIyjEcB8N1+mLYgkLMwmOi28QBDCxSElPuG0tD5BlU5P4yME6J?= =?Windows-1252?Q?pcZT4i5cgoEkkY4N2e7U0naTXbRPEgfc4mLUdK0JVDW+/wqtriVVvp8A?= =?Windows-1252?Q?mVFGghnJYS7ZD1vHa0fusHSGEDEe5sBd1BMGOQCNerHjJjoSFHy5NuoG?= =?Windows-1252?Q?wzcpVIjRBePrlMJ0ieN3Edu1c88xEujaMyR75XTTRQoPoXMkKgUpDqrV?= =?Windows-1252?Q?IRwxMTj79Syjo3zNKCtKKU6xwGUO1vrjgirBSsamq5pRxrur08x6m2HV?= =?Windows-1252?Q?ILEuEdjHHWk9hxC4k22kvuOC954aSxeYuOTon7zEp/ILwEus5HOa2LqN?= =?Windows-1252?Q?5uSnTWcjCYAummF1tEuTOXGPD7sS6oUNKc9vYa4HnZsgM8ygqwrjEnIj?= =?Windows-1252?Q?mXxHAhER4Awwvt1omnexFIrRxRxhRVhdqQLZPxM6NyNEy/h51X2UeHYH?= =?Windows-1252?Q?LZB+ylkkqwBCe1ZE5ZY6MkhOldb//JmdWBC5kIXGoqMUPuYRTtu9E0aJ?= =?Windows-1252?Q?YZCpcN0D2P+LrbD/U8Fjdb7Qu/RDCHqR2NFLkgmj1LNEwFrkHdKyKLIi?= =?Windows-1252?Q?GpW53YZexM64Zq0CmhW/OAcdKTEQddpEK93hJA=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)(1800799024)(376014)(8096899003)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?2+N16C6VOxcMABUkODE4u/42yy3g5wjX4h2OEDQIKcMSlpSEy1lxR6Nq?= =?Windows-1252?Q?BPwAcNUjF9daCbB9auLTODTvS+HZxLX5J47UXwBiJgrxOucx0Vf95RqR?= =?Windows-1252?Q?Dp2uor6leLi0RjZ841YSE1TvAUmQDx8k/nrWE6paqjbMtlv9fgPA/0w7?= =?Windows-1252?Q?zX/+iaOjLPWaFuhWuY8FpIzHROa7HU/amilNaOvQVd1SgXjFyEDI4ooo?= =?Windows-1252?Q?u+SDkqLM+hVsOWvjhEXHAQl6pWUZWZgtbi4IiiIapTRavYuxA2C0RH1y?= =?Windows-1252?Q?DrtF+qSM36tebl302L0eELE7sEoTPE+kvfS61juCAiOfxOdqDvZHyVaY?= =?Windows-1252?Q?r0fdOiMlzoeR/4Am0zjEWgA01cYZ74hw2NLyoSEXNOD24blWpw68ek2/?= =?Windows-1252?Q?nSpnCVkDivaLtzSKAm4Mashx5hSywi7+yUA+bEY6s5dyy5AmI+aa72L4?= =?Windows-1252?Q?uG2eMlSJ3vHFc7KMNgPswRi639XX+8qzIX//KbwaF4lfOuRCZ/WGk04e?= =?Windows-1252?Q?7E4CaNNdObA6bTW1ivYN48k2CDNYejZ3Cwy8+d+CeJowHsDe31uI9iuL?= =?Windows-1252?Q?QaRId/tKGRaOIzSXk5w8TOu4n/klUJOFuT9xO3EYC5Y/n6H6p++AtuMc?= =?Windows-1252?Q?0E3UGT0ZQkiOaUUwhzorao21HSfqyj1DCX8CgGIVUIvZN75vFO7Vg2nM?= =?Windows-1252?Q?jZrg5fE21EO5sj1yHhOeZtQM4hvOFe1CWyLr2h1swNiu9ZWo41CIIYQe?= =?Windows-1252?Q?L39GSnlJq+TPYHeirdAdOS8226jmwAFgzKGxn2A3VJDNdkvfxSO1yrCH?= =?Windows-1252?Q?Y55l+ictoYs5gKAed0ACvnYPi1hWGZdvGkgOe3qIr2I4hwjnjR67KMRJ?= =?Windows-1252?Q?2XttKz8togxq1/z3M4V46/gMuEWHUKDPBsNxAxhLJ0owfu/c4z/4gMjc?= =?Windows-1252?Q?NYGxmveW3bOlcXg8p//QIalberDnGQrXvZvQnDncjtAXvgOoaK8VvS2B?= =?Windows-1252?Q?Vaw/hZ+UEGQg1Xpi/qyxe3jHepx9RlXgNNFENZknNvkm6bo7Zv8oUp2d?= =?Windows-1252?Q?dpagyXR52PQV+b5tvS0iKPt7JoZzE7oH+lzAa/LIGgrPyrjmUx6VBHf9?= =?Windows-1252?Q?rTnox64vcGQJjO8iBCMOY37TIsjPOd01S/TF2NAvjQCI97d6IhMOO7iM?= =?Windows-1252?Q?RBRvXcK5d9qV6NMLX+c4BQNn+LghAERNLWHQ5lqeQvuVKqtXwhk1WuKV?= =?Windows-1252?Q?p6LX6MFLaaKTiwLtex6aOdIYOcCm/N9eUJsPp1XyR9r6p/ycOpFRIpWm?= =?Windows-1252?Q?W86tpyyuHchzqrwDkyr8T0ddTkbnlnecTKJHzezPA2FVOr7mbEtGuN0B?= =?Windows-1252?Q?j5lqh1mq9f7bqVeZh97L8n3IeDi/bK96wJbD3vuZpH45e6/VVTVfdYhd?= =?Windows-1252?Q?ie+d3AdPlyznmYBsriylyu081emUSSq2JI30wMmeY3qZZlg54Ne+9gFk?= =?Windows-1252?Q?52jmXHoaIX7F+Zf2shsUtXygq5Q4pNRbN4vBNwPwIy2zUDjqI+rrNq4f?= =?Windows-1252?Q?YFpIhA55y45JT9Tm/GROwcAuH6DSFh5lTN2l8LyqEx8VUUMIrNHJXWnN?= =?Windows-1252?Q?wgMN39ABQe4rPG1oGeuSO8UctONIOPTk2FoOig86DWJO/5qWlRiOQjSr?= =?Windows-1252?Q?a+/NlsvtRiVRYFpq7WcF/EiuUIsYh6Hf?= Content-Type: multipart/alternative; boundary="_000_SN7PR11MB76383BC715B6C80ADA0A87CEF957ASN7PR11MB7638namp_" 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: 4eb5e6f2-3b1b-441a-f816-08ddc38a5468 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2025 10:28:24.5168 (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: EkE3f8ma1jThQh5sr5/uBstNL9VHIzW0N0569rJUqvbiDxrAfTb8ew6KlG/LHCl4/fRXzjmzPF7zbKYTRZRMKZlJseSob/yjO58OD/71BPs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB8066 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_SN7PR11MB76383BC715B6C80ADA0A87CEF957ASN7PR11MB7638namp_ MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable 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=92s 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@sourcewar= e.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. 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_SN7PR11MB76383BC715B6C80ADA0A87CEF957ASN7PR11MB7638namp_ MIME-Version: 1.0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
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, regis= ters."
> 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 of registers
or parts of registers."

>> The SDM uses the term xstate_bv for a state-component bitmap, whic= h is

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

Do you mean writing it out to "Intel Software Developer=92s Manual&quo= t; ?

> I'd like to ask about the use of 'mask' in this variable name.  W= e 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 x= state_bv
instead of xstate_bv_mask 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 confusing and I will rename it to xstate_bv.

Christina

From: Andrew Burgess <aburgess@redhat.com>
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.bauermann@linaro.org <thiago.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 Add= ress: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0,&nbs= p;www.intel.de
Managing Directors:&= nbsp;Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva

Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Mun= ich
Commercial Register: Amtsgericht Muenchen HRB 186928


 --_000_SN7PR11MB76383BC715B6C80ADA0A87CEF957ASN7PR11MB7638namp_--