From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id COMuDZ2rkGjUswMAWB0awg (envelope-from ) for ; Mon, 04 Aug 2025 08:46:21 -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=RgDQFvXW; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 233321E102; Mon, 4 Aug 2025 08:46:21 -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 186B81E091 for ; Mon, 4 Aug 2025 08:46:19 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 944A2385840E for ; Mon, 4 Aug 2025 12:46:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 944A2385840E 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=RgDQFvXW Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by sourceware.org (Postfix) with ESMTPS id A1E0E3858D29 for ; Mon, 4 Aug 2025 12:45:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A1E0E3858D29 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 A1E0E3858D29 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=192.198.163.9 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1754311541; cv=fail; b=HMyZkZmn9r5eIgDFZmEGRIdpCQmcRVdafLbhinUMnX52XDCLeI11wUi4fhLd0tqE0MhUE5OIdp7/cejVij1xfv/o/MZw8JVK+JUBpG+5gxWojpl0JThwMs42l6rMcZDm/mKXCK3mXUAhEQFgtynL7jViv+MioEE2ER+L2uwinnE= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1754311541; c=relaxed/simple; bh=G48V0WCTsoRpnh7cyVKZWcTfvG517gEY0pZRlFiXX0I=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=EZ2sHtSh/pM8qlgpRVFDFuKeoF6MXz2j63/6eYklaecLNjy9lbGXXfysb4BBSZIJ3DAf5gZpurDr0KEiTkoiXbG7qK7DeG4/jj9gdIjkXNyBLmjYIl0h9r4D+Lev6aGH5mU2yQuD56EhJzTgwtf5mT+dsSvAtPnqtRH5474S2U0= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1E0E3858D29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1754311541; x=1785847541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=G48V0WCTsoRpnh7cyVKZWcTfvG517gEY0pZRlFiXX0I=; b=RgDQFvXWWsGrH27Qq9XOWNidsEYb1/06NwClNvC6xYQmXEF/yRJl031z vD4BCo8MOxpnYuGx9a+oONdaBuFnVNpjIHclmhPc7udpY8HCmd6T6XR5X qiSbJB4hvlvoY+VQGqaed54YJG83eGYyqlRw1y/atrnR8tvMFiax8m8al Bv7Keuj7Yum9nmEcycSkiEtIrBpPPwujr5XeWD8p90S3P/HNPnOKwKNhT sr3nENOffIUTjI+eUcpTHUleVWD6ScoQTuBHVKBDbI9b0ow1UzX3dHSZw w0fintT1Clpx3tIFUaSetNKnFpppbEOZM5KtJyrpij9C4TRp6mts7c7l2 g==; X-CSE-ConnectionGUID: e4FTXiXlS3iKqr2H5vSqxg== X-CSE-MsgGUID: CJGL90LGSv+IY4e5UyMHyg== X-IronPort-AV: E=McAfee;i="6800,10657,11511"; a="67271409" X-IronPort-AV: E=Sophos;i="6.17,258,1747724400"; d="scan'208";a="67271409" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2025 05:45:39 -0700 X-CSE-ConnectionGUID: W5T4Vq88SM+crSwgX0vLGg== X-CSE-MsgGUID: iws13pCqRMmTCuyhAYe2Cw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,258,1747724400"; d="scan'208";a="164600907" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2025 05:45:39 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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; Mon, 4 Aug 2025 05:45:38 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) 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 via Frontend Transport; Mon, 4 Aug 2025 05:45:38 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (40.107.236.55) 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; Mon, 4 Aug 2025 05:45:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fWElhsIA5wCoJgSOFufxHCEn0SYMqeUrbNUZ4rJ+uLQEUd/o1XGeooA8FHa3492sKgVlrljzKbNV4NKlMnOante4ye6jkQN9L5zj9MEZEYLs6JBpMkiFlGGzYPILTQdCKLEkMf99eu/Zw9eayW4c7G/VFjQqdOUf9jBEhE5nsZv+63rzk/UBnCI1W5rHYDfzmYvj4ZU4wfWbDOXmu+o3Gmd6pgRKCqiDrYmx6gLRknBJZdMoV/Puw/KEBbPvzYmschjqRh+ZH+yIEMAxwFwLmYNpIfwiQzBy2y4NcmDt0fZroiCBVFXsqtlNwy210BdKiBM8ZWxBADsZhyi38aAdeg== 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=zDJUaNE3a4mnzKU4FZ7iZCH6/80P/Ly22NZUtmhVtAc=; b=vx6q50XL8ZVT2Kjd0G80tYShjHM1aTIYH0o11c2LarRmXGfvtDY8byEXTPHi2qNGmzWYxeGbQjp2MZ/yRRrqO2PQXxAG1jcch0k84KsES+DlO+8x8XuDMxy1M/jJ5Vfv+rIwPUWcUTycvFr+5KQkZR0uY0W/4eK/ugeJGKTC2249WKqAttcWNXE71DxY0YR/I/BnwWKYxyC3SrQCpfDNUb005QtMD92VDgQjOJKVPrJxLQbXx6xv1oJ6SWvip8nMao+vygFfCG2O7WtUPtyocX/h8pjTzt3OBkoTrAAWrOmPpBkGVpVZYiKmUDxleMEowF3930MWGxXW0CwkeCHdHQ== 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 IA1PR11MB8785.namprd11.prod.outlook.com (2603:10b6:208:599::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8989.20; Mon, 4 Aug 2025 12:45:35 +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 12:45:34 +0000 From: "Schimpe, Christina" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: "thiago.bauermann@linaro.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: AQHb6AdfopZEH8KoZUSF1KMGj5X1tLRJXyMAgAkuinA= Date: Mon, 4 Aug 2025 12:45:34 +0000 Message-ID: References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-8-christina.schimpe@intel.com> <87o6t3cawd.fsf@redhat.com> In-Reply-To: <87o6t3cawd.fsf@redhat.com> 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_|IA1PR11MB8785:EE_ x-ms-office365-filtering-correlation-id: 49097b7d-399d-47e9-1b1e-08ddd354ce40 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|376014|366016|13003099007|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?OjfgCqoB19O0Ed6EEFKILPhPamJ3LL2QqMQFLwgsQGgLOuiQpnGe/+6tvk9s?= =?us-ascii?Q?FiwQ4cDmzo+YGhGA3Sj5Xt6O14VhgwCVaIueu3h7YGKtKNNjKygAp1Bs+YdS?= =?us-ascii?Q?ZDHJB6NCpfD2TEi0ACX6e3tLLV0GiuC0NkOZKVYTngqDHB+qlMichW4Sow3P?= =?us-ascii?Q?bZD3NNK+6ilU88M0zhgvpfpcS1A2VdOV8NpMYkZGjajE8lTa7m8zZ+c9RdMY?= =?us-ascii?Q?/K8/3kIqjd2zidKPmwTK8P5bsPo4AVR6+F1SjOvGksp4AyzcLuepgKkK1FHU?= =?us-ascii?Q?Z9cYRetIGmjtWIx9WgE77oqrv4ajP4viSLKvVBKyKeEUbo9WEsGWbOMWRx1Y?= =?us-ascii?Q?pv2okadCiLMHOp0Lba5jw9i0uV+I6CeODlGKZspUmgsjseuIU56mmbHTMezt?= =?us-ascii?Q?Beh2actcPlSgiaPyYVHBVJdz6fNkMoX+1eLuHJAJszEjMgI2DBtlFwW/9dtb?= =?us-ascii?Q?0wdhub34GaLz++tZPCXt+TgbGvwnGmKKPdNanf3ND7ijPsvVHYaI2gR7ROx5?= =?us-ascii?Q?R2e9wsZuM/FZRksid2WD1t+hOZozoXsJF+vlh2eniBNMxieDYhdaB7kbVAn4?= =?us-ascii?Q?yiAZP2kqpvQEXDOGEkNqy5UNdVY4WHfJ+brLXbaGTpyBree8nNur7IWekBSy?= =?us-ascii?Q?Oy89Cz8tV6pWMbdnX5M9WQXr/WZFdLcGZydgt6VZ4qvz/BxBPajmVakCRJVq?= =?us-ascii?Q?j/L1L94k80w4QLuNCGYasHJoOqeBvk840EQoqCw+DMR0rsFgMHbEAZpO3ggu?= =?us-ascii?Q?ENDNYuuaHhj56CYJOxDBoOL6Xibsx8a2eaPvfmxKBYj45xSH1XcQHkhBl0D3?= =?us-ascii?Q?2x3/6AgbYt4WVoztIISzg/NrldXz3RYtRyvngWPnKc/OiPOKmwQuLJrk+UUl?= =?us-ascii?Q?lacSXfFc56ZJ3PTBMouAkl6EcCg+NqvZ7hhWPBHSW8326H7NsGpTZnHJAM5q?= =?us-ascii?Q?ixP6ahcerwrFsd0ot6s3L5zqne/S3bF2zn47onHXfXSRdupi8u40t6ryKGu1?= =?us-ascii?Q?Dk/1483+lG+Fwo/gbm8TfOCsS4zmxqolUe0VFWkbn6eXgklOG0r0LE0RhIDP?= =?us-ascii?Q?lCT1gzu+65cNvNvmcq9kcYS4REMPC7zdcb5jkvpmzQbDPaeneS30dHccFPG4?= =?us-ascii?Q?A1Ver8AkIdKsqKsg/qQj+kvxATeVsMK2WS92E9UgKoC5xtCxQTnEjNI9rmpe?= =?us-ascii?Q?6iVhGrVzmRWg4ie88S/xO8ZHjIITIpoPQibZPQ90ADXNC14Hd0K6MC+OToRO?= =?us-ascii?Q?1bIG/21jhvjEatw3zpqT6No32LhAmOc+hJLjFQcC0YAfn4u59d9kO+0nTa/5?= =?us-ascii?Q?kHlzt9psdD6g4Muar+4jKEZePO/EVRFpSSwajv+sS4oCGqD4WJ+a0aJv1nZN?= =?us-ascii?Q?G85trTETjh7aTs2YopS23iac8AcZz6Lw7K3xTR/AOH5pRowCveXVTWD/hkxC?= =?us-ascii?Q?iS4BDOtZ/eFmIm0z7wZptDg8ymdmkz+cwnl/vGF1g4Xh20QlO/fILFMyu1s8?= =?us-ascii?Q?W+0khRbNaPDy4mo=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)(1800799024)(376014)(366016)(13003099007)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/yCFL+bYXBG9m4qikd2vW+0MEGG6Onif/ot0s9xOghwueWaAau+2wDT041l+?= =?us-ascii?Q?emErY8nxJ7c8E61TbwkzoTJkC9V/Qai3+AjeseJxxDVQqJopesQaE1byOtO2?= =?us-ascii?Q?YkuHL8pCsL0cv33I8kLmmnHTxKTaHXfPYL7cYUax23WgQmrh2S2QBoYbwlL6?= =?us-ascii?Q?uIY+enRbVbIhLUSbKKjnqMga8zr0/DRtUc7FfKkIZvPEjWv9o+oQWQRJj1Jw?= =?us-ascii?Q?54Pw9fuwJgZ2PooHjhGYqPIVpiZbYJir8pG11hZ7f81xN8tm/BNzzUcBOr3G?= =?us-ascii?Q?T3yuFtubMKu4KPYtDb7w+XLx2TkH5tPJQbHm5yKTXjvGkZe39xYrWZG/x6Wg?= =?us-ascii?Q?xovqmOA7xT7XkebVYQsQfW5omKLFhEkQyYpURdmIZPKwMNJ3+G7JtYKTXr2a?= =?us-ascii?Q?HrmA3av6RmYg/DMQBLbD6qneqqQA45obgrJWx/+JnnHwBucm6uTi3iZdaYkD?= =?us-ascii?Q?4T57C5B5UVQB/9oaCDzYrF4H8oobdtryS45oT0hd9rbys3sLz96maIa0gcwK?= =?us-ascii?Q?cPJiCQdu4XCiOtptghikNswDAicMK7ezJ+tGGSg3JRZaEzn5Dy6QXf9v3+h2?= =?us-ascii?Q?zJYpj2SbxqmRzSXA0xJa1QeUxNJvR3FVpXXC2U4iRCbhs7wO+5rX7jrwoeBI?= =?us-ascii?Q?YJXESs6LgIaD1GQfZJAwuRkbIN6G6v8Sh4gejSSXz56gWy2nX/u9rTWZ96/g?= =?us-ascii?Q?AiTgQIJ9LopP+GqvmLkHU4GlLYKimiMEe+21KTig7mwn8vql4j7yHJURW0zd?= =?us-ascii?Q?eJ0gWWiPMpdx7BdrsdNQBd2EjkffD+Xy102b5/8IWyibu8qA8Q8B0jilW372?= =?us-ascii?Q?f+w4us7TqYcebFvAqfSH9cj9oJEifbKMhvi97ZPBX78sbggFpayKzfmgJ0wX?= =?us-ascii?Q?s0+h8FA83puextORT/FXirOAo8Nz9/gk9SsO6YAwp3onwkLnhzwutsP8Uh/Z?= =?us-ascii?Q?MFAXTsiXYG0kIdtopkcCCNYJGRnxQGErj6ccbhL4AGLAmVOBe1yrqhITfI7M?= =?us-ascii?Q?nl8Tqc71+AiOhbq2S2LgrCfgOBT8ybEtW7RH883Gq3FG04ONWqlIg4jpPJ2w?= =?us-ascii?Q?ou3fHyI6fvZshGiWP9yPN4exuUHuoN/v2fiVSFsEJnmY+JA6Ai6mUxZGA0gz?= =?us-ascii?Q?1IYqu1jZtB7c6P4mJ3R82XXadr5UBtbA1gibAVtCVNsFSKuXhuBIkj9IAC7H?= =?us-ascii?Q?TqqyqMmBYOq+NalnYlv6iH5pw/yHAaqbKMNlY8nzmn0Wv9PwAUzb1AWe/vtn?= =?us-ascii?Q?CKGRTsNW5ajV8bU3jHvwsNmJCw2hWp75Rf2nN5FxPlCIzPVDXdD/zlrcy5DY?= =?us-ascii?Q?xBR7wCpjeGjFBMWZzyp0VCpxMWosj+FLrbAn4bF945o6KIphgyqyaWSoTqef?= =?us-ascii?Q?wPq5aa0tqHuyBTzAWHmoZrpFLvMeYew1jCvWHY829IGz+adtVB/M2wgo1mFm?= =?us-ascii?Q?ZlICf7BDQtVdq/dNoZQcKovL9rmaiLbMUie0GZQJq5uWY/Ad2men6eKbsRfy?= =?us-ascii?Q?Fo7TcsYCFeP9RYtsXoUxElT9uBMddhCXa/JRkDuXrWqG61zniozVB1Pv0tuO?= =?us-ascii?Q?qHIZQiuw+LR51Du1hA2bt0Pw670fGAPJB95wEXWKE25XOtqlt1liRSW53HT/?= =?us-ascii?Q?Rw=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: 49097b7d-399d-47e9-1b1e-08ddd354ce40 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2025 12:45:34.6695 (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: rrRZqNbZee/kJSoFT1eE/Zwsh7YnT1iFCD7MUjSIh4lpGSoX0D7aDIkP5117oeNEoeoqFdFHxGs17sZHhbaQmtz4ROWiT14GZOXm9nV8DTo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB8785 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 Andrew, = Thank you for the feedback. Please find my comments to your feedback below. I'll only comment on the non-test part, since for the test I already replie= d in: https://sourceware.org/pipermail/gdb-patches/2025-July/219525.html > -----Original Message----- > From: Andrew Burgess > Sent: Tuesday, July 29, 2025 4:47 PM > To: Schimpe, Christina ; gdb- > patches@sourceware.org > Cc: thiago.bauermann@linaro.org; luis.machado@arm.com > Subject: Re: [PATCH v5 07/12] gdb: amd64 linux coredump support with > shadow stack. > = > Christina Schimpe writes: > = > > Intel's Control-Flow Enforcement Technology (CET) provides the shadow > > stack feature for the x86 architecture. > > > > This commit adds support to write and read the shadow-stack node in > > corefiles. This helps debugging return address violations post-mortem. > > The format is synced with the linux kernel commit "x86: Add PTRACE > > interface for shadow stack". As the linux kernel restricts shadow > > stack support to 64-bit, apply the fix for amd64 only. > > > > Co-Authored-By: Christina Schimpe > > > > Reviewed-by: Thiago Jung Bauermann > > --- > > gdb/amd64-linux-tdep.c | 57 ++++++++- > > .../gdb.arch/amd64-shadow-stack-corefile.c | 42 +++++++ > > .../gdb.arch/amd64-shadow-stack-corefile.exp | 110 > > ++++++++++++++++++ > > 3 files changed, 205 insertions(+), 4 deletions(-) create mode > > 100644 gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c > > create mode 100644 > > gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp > > > > diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c index > > edb7d8da6ab..9af7a41ea26 100644 > > --- a/gdb/amd64-linux-tdep.c > > +++ b/gdb/amd64-linux-tdep.c > > @@ -47,6 +47,7 @@ > > #include "expop.h" > > #include "arch/amd64-linux-tdesc.h" > > #include "inferior.h" > > +#include "x86-tdep.h" > > > > /* The syscall's XML filename for i386. */ #define > > XML_SYSCALL_FILENAME_AMD64 "syscalls/amd64-linux.xml" > > @@ -1593,6 +1594,14 @@ amd64_linux_record_signal (struct gdbarch > *gdbarch, > > return 0; > > } > > > > +/* Get shadow stack pointer state from core dump. */ > > + > > +static bool > > +amd64_linux_core_read_ssp_state_p (bfd *abfd) { > > + return bfd_get_section_by_name (abfd, ".reg-ssp") !=3D nullptr; > = > I think the comment on this function is not correct. We're not getting t= he > shadow stack pointer state, we're: > = > /* Return true if the core file ABFD contains shadow stack pointer > state. Otherwise, return false. */ Agree, will add. > = > > +} > > + > > /* Get Linux/x86 target description from core dump. */ > > > > static const struct target_desc * > > @@ -1602,11 +1611,14 @@ amd64_linux_core_read_description (struct > > gdbarch *gdbarch, { > > /* Linux/x86-64. */ > > x86_xsave_layout layout; > > - uint64_t xcr0 =3D i386_linux_core_read_xsave_info (abfd, layout); > > - if (xcr0 =3D=3D 0) > > - xcr0 =3D X86_XSTATE_SSE_MASK; > > + uint64_t xstate_bv_mask =3D i386_linux_core_read_xsave_info (abfd, > > + layout); > = > As with feedback on earlier patches, I don't think the inclusion of '_mas= k' is > a good one here. I think what you call xstate_bv_mask is an actual value, > not a mask, and should be named 'xstate_bv' I agree and will fix. > > + if (xstate_bv_mask =3D=3D 0) > > + xstate_bv_mask =3D X86_XSTATE_SSE_MASK; > > + > > + if (amd64_linux_core_read_ssp_state_p (abfd)) > > + xstate_bv_mask |=3D X86_XSTATE_CET_U; > > > > - return amd64_linux_read_description (xcr0 & X86_XSTATE_ALL_MASK, > > + return amd64_linux_read_description (xstate_bv_mask & > > + X86_XSTATE_ALL_MASK, > > gdbarch_ptr_bit (gdbarch) =3D=3D 32); } > > > > @@ -1637,6 +1649,35 @@ static const struct regset > amd64_linux_xstateregset =3D > > amd64_linux_collect_xstateregset > > }; > > > > +/* Supply shadow stack pointer register from SSP to the register cache > > + REGCACHE. */ > > + > > +static void > > +amd64_linux_supply_ssp (const regset *regset, > > + regcache *regcache, int regnum, > > + const void *ssp, size_t len) > > +{ > > + x86_supply_ssp (regcache, *static_cast (ssp)); > = > Before this line I'd like to see: > = > gdb_assert (len =3D=3D sizeof (uint64_t)); Agree, will add. > > +} > > + > > +/* Collect the shadow stack pointer register from the register cache > > + REGCACHE and store it in SSP. */ > > + > > +static void > > +amd64_linux_collect_ssp (const regset *regset, > > + const regcache *regcache, int regnum, > > + void *ssp, size_t len) > > +{ > > + x86_collect_ssp (regcache, *static_cast (ssp)); > = > And I think this should get the same 'len =3D=3D sizeof ...' assert as ab= ove please. Agree, will add. > > +} > > + > > +/* Shadow stack pointer register. */ > > + > > +static const struct regset amd64_linux_ssp_register > > + { > > + NULL, amd64_linux_supply_ssp, amd64_linux_collect_ssp > > + }; > > + > > /* Iterate over core file register note sections. */ > > > > static void > > @@ -1653,6 +1694,14 @@ amd64_linux_iterate_over_regset_sections > (struct gdbarch *gdbarch, > > cb (".reg-xstate", tdep->xsave_layout.sizeof_xsave, > > tdep->xsave_layout.sizeof_xsave, &amd64_linux_xstateregset, > > "XSAVE extended state", cb_data); > > + > > + /* SSP can be unavailable. Thus, we need to check the register stat= us > > + in case we write a core file (regcache !=3D nullptr). */ if > > + (tdep->ssp_regnum > 0 > > + && (regcache =3D=3D nullptr I'll change the = "tdep->ssp_regnum > 0" to "tdep->ssp_regnum !=3D -1" as discussed already. > Have you really seen this function called with 'regcache =3D=3D nullptr' ? > I'm suspect not as e.g. i386_supply_gregset, which is part of i386_gregse= t, > makes an unchecked dereference of regcache, so if regcache was nullptr > you'd see UB (crash) before getting to this check. We see this if we load a corefile: ~~~ (gdb) core core.3499583 [New LWP 3499583] Reading symbols from /tmp/main... Thread 1 "gdb-up" hit Breakpoint 1, amd64_linux_iterate_over_regset_section= s (gdbarch=3D0x5555589cc140, = cb=3D0x555555fdd64f , cb_data=3D0x7fffffffad20, regcache=3D0x0) at /tmp/gdb/amd64-linux-tdep.c:1694 1694 i386_gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch) (gdb) bt #0 amd64_linux_iterate_over_regset_sections (gdbarch=3D0x5555589cc140, cb= =3D0x555555fdd64f , = cb_data=3D0x7fffffffad20, regcache=3D0x0) at / tmp/gdb/amd64-linux-tdep= .c:1694 #1 0x0000555555e15491 in gdbarch_iterate_over_regset_sections (gdbarch=3D0= x5555589cc140, cb=3D0x555555fdd64f , = cb_data=3D0x7fffffffad20, regcache=3D0x0) at /tmp/gdb/gdbarch-gen.c:3840 #2 0x0000555555fdd876 in core_target::fetch_registers (this=3D0x5555588ee4= e0, regcache=3D0x5555589c9120, regno=3D16) at /tmp /gdb/corelow.c:1425 #3 0x0000555556744d0a in target_fetch_registers (regcache=3D0x5555589c9120= , regno=3D16) at /tmp/gdb/target.c:3915 [...] ~~~ In corelow.c: core_target::fetch_registers we can also see that that we pas= s the nullptr: ~~~ struct gdbarch *gdbarch =3D regcache->arch (); get_core_registers_cb_data data =3D { this, regcache }; gdbarch_iterate_over_regset_sections (gdbarch, get_core_registers_cb, (void *) &data, NULL); ~~~ > > + || REG_VALID =3D=3D regcache->get_register_status (tdep- > >ssp_regnum))) > > + cb (".reg-ssp", 8, 8, &amd64_linux_ssp_register, > > + "shadow stack pointer", cb_data); > > } > > /* The instruction sequences used in x86_64 machines for a diff --git > > a/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c > > b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c > > new file mode 100644 > > index 00000000000..f078e33810d > > --- /dev/null > > +++ b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c > > @@ -0,0 +1,42 @@ > > +/* This test program is part of GDB, the GNU debugger. > > + > > + Copyright 2025 Free Software Foundation, Inc. > > + > > + This program is free software; you can redistribute it and/or modify > > + it under the terms of the GNU General Public License as published by > > + the Free Software Foundation; either version 3 of the License, or > > + (at your option) any later version. > > + > > + This program is distributed in the hope that it will be useful, > > + but WITHOUT ANY WARRANTY; without even the implied warranty of > > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + GNU General Public License for more details. > > + > > + You should have received a copy of the GNU General Public License > > + along with this program. If not, see > > + . */ > > + > > +#include > > + > > +/* Call the return instruction before function epilogue to trigger a > > + control-flow exception. */ > > +void > > +function () > > +{ > > + unsigned long ssp; > > + asm volatile("xor %0, %0; rdsspq %0" : "=3Dr" (ssp)); > > + > > + /* Print ssp to stdout so that the testcase can capture it. */ > > + printf ("%p\n", (void *) ssp); fflush (stdout); > > + > > + /* Manually cause a control-flow exception by executing a return > > + instruction before function epilogue, so the address atop the sta= ck > > + is not the return instruction. */ > > + __asm__ volatile ("ret\n"); > > +} > > + > > +int > > +main (void) > > +{ > > + function (); /* Break here. */ > > +} > > diff --git a/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp > > b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp > > new file mode 100644 > > index 00000000000..8784fc3622c > > --- /dev/null > > +++ b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp > > @@ -0,0 +1,110 @@ > > +# Copyright 2021-2024 Free Software Foundation, Inc. > > + > > +# This program is free software; you can redistribute it and/or > > +modify # it under the terms of the GNU General Public License as > > +published by # the Free Software Foundation; either version 3 of the > > +License, or # (at your option) any later version. > > +# > > +# This program is distributed in the hope that it will be useful, # > > +but WITHOUT ANY WARRANTY; without even the implied warranty of # > > +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # > GNU > > +General Public License for more details. > > +# > > +# You should have received a copy of the GNU General Public License # > > +along with this program. If not, see . > > + > > +# Test the shadow stack pointer note in core dumps. > > + > > +require allow_ssp_tests > > + > > +standard_testfile > > + > > +proc check_core_file {core_filename saved_pl3_ssp} { > > + global decimal > > + > > + # Load the core file. > > + if [gdb_test "core $core_filename" \ > > + [multi_line \ > > + "Core was generated by .*\\." \ > > + "Program terminated with signal SIGSEGV, Segmentation > fault.*" \ > > + "#0 function \\(\\) at .*amd64-shadow-stack- > corefile.c:$decimal" \ > > + "$decimal.*__asm__ volatile \\(\"ret\\\\n\"\\);"] \ > > + "load core file"] { > > + return > > + } > > + > > + # Check the value of ssp in the core file. > > + gdb_test "print/x \$pl3_ssp" "\\$\[0-9\]+ =3D $saved_pl3_ssp" \ > > + "pl3_ssp contents from core file $saved_pl3_ssp" > > +} > > + > > +save_vars { ::env(GLIBC_TUNABLES) } { > > + > > + append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" > > + > > + if { [prepare_for_testing "failed to prepare" $testfile $srcfile \ > > + {debug additional_flags=3D"-fcf-protection=3Dreturn"}] } { > > + return > > + } > > + > > + set linespec ${srcfile}:[gdb_get_line_number "Break here"] > > + > > + if ![runto $linespec] { > > + return > > + } > > + > > + # Continue until a crash. The line with the hex number is optional > because > > + # it's printed by the test program, and doesn't appear in the Expe= ct > buffer > > + # when testing a remote target. > > + gdb_test "continue" \ > > + [multi_line \ > > + "Continuing\\." \ > > + "($hex\r\n)?" \ > > + "Program received signal SIGSEGV, Segmentation fault.*" \ > > + "function \\(\\) at .*amd64-shadow-stack-corefile.c:$decimal" \ > > + {.*__asm__ volatile \("ret\\n"\);}] \ > > + "continue to SIGSEGV" > > + > > + 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"] > > + > > + # 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 mis= sing > something here? > = > > + > > + # At this point we have a couple of core files, the gcore one gene= rated > 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 th= e 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. > = > 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? > = > > + } > > + > > + 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. > = > Thanks, > Andrew > = > = > > + } > > + } else { > > + untested "OS corefile not generated" > > + } > > +} > > -- > > 2.43.0 Kind Regards, 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