From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tZzCNK5cWmiQ6hsAWB0awg (envelope-from ) for ; Tue, 24 Jun 2025 04:07:10 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=U1Ji07c1; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=U1Ji07c1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C42ED1E11C; Tue, 24 Jun 2025 04:07:10 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 6FDA91E089 for ; Tue, 24 Jun 2025 04:07:08 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 15FD23858031 for ; Tue, 24 Jun 2025 08:07:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 15FD23858031 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=U1Ji07c1; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=U1Ji07c1 Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazlp170120005.outbound.protection.outlook.com [IPv6:2a01:111:f403:c200::5]) by sourceware.org (Postfix) with ESMTPS id DCE793857C7A for ; Tue, 24 Jun 2025 08:06:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DCE793857C7A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DCE793857C7A Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c200::5 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1750752388; cv=pass; b=NdlpTlLJIe+gNFtPjgxEYrFnNj012nCp56j/2hEwgmLVfAdogA4xcFNxx57Y/D9pjEXsaO6f+FpS86AZ2W6KB2j4wEBeGKEX97Fb86Yo6TxTv4q0mf11twCMIX3lVlthlpG6LwVx/YWWLGrAWaZcJEUbj6aadnBzqjuSEm5RV1Q= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1750752388; c=relaxed/simple; bh=RUws7u+gIvGjvF7Zn47DPSFgrPPtkh7fMPjLt9+1iCM=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=iXt3hYDcibfm4JBLaZZIC1NwAhl3Pn5WGRcJKWs+Q2Rm/2YbWjSZHmNXUrnWja/ygSzyaH55eH/Rx8/AZUNL0bVGQomjeanyunQDq6hbOy69XCrfOjBXMKtbC5ibvUPtJhohWx8VA9ZmQiCqqWzcA2865KdEB7qnIjkffOId24k= ARC-Authentication-Results: i=3; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCE793857C7A ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=vlYwx29a9LpKO6GaFwujfz4gRb9vtrigRCtso0JkYYC/QyhiPIVsCrkuEiYJVE9QZaYyhrBUFzqEdXl5Y3QdulQLgEwe3l2MGaDh7Rbfuy4jS1hyr5X8OgVZheWv0ag5EJA92XW91pMEmF0bDfjfEDX+UpPj1GjJG98EIegK1u66qkxBMuDg/Q6a7h6w8l66JHQxkrw3ehsD2cktay1StkLUCNbk3zYZGw2AhL7xV1gEWXCasM2B2xzzdRBFzh5pzTTk8Lcged42QUFeEUu4m5UmoH8WKuEeNROjRey9rUUC1zs4ILCT7OanmVRwJXklEZBB9oIfywkLSRwgGqiZfw== ARC-Message-Signature: i=2; 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=lQxyQ5iy77ih4OPBvSCcFxyNinYVT9OPL5tD3c5pQyU=; b=bQ/sROrXpNGvI+vQjnu+zJIwj7ncis982dbdQbxgqWgWTjPhs8Bvyfsy62pUoGuEmSA3SU7FkzTobG/HWBoH7xVc/IofQwOWZxyYuSZOK5yC+W8W4tv4pf7c/hYuiWIdNyCgRMvgFOjxNOLsj8dhlHExVqehLCA/XVuWFklR9kIg5AHPlzOEz03Xd/SgrrOxKpzUyGq/VYtcwLSUA8aFDWEDm0cKAfKjWU8j8XINJFRf4xaZUykEOX3hAlCHBoWB4e9aBx671zGdNzPtDEqtC7mK++RzsWAkpVTsx9c+kWbYPa3CqOB/yXOgBMJ1DjVvZZ664gG2dy2aJkyJnDB/cw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=intel.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQxyQ5iy77ih4OPBvSCcFxyNinYVT9OPL5tD3c5pQyU=; b=U1Ji07c15cyrrEgnrsxwlEUOqICKbPivHfL5k+ccZp9K1XGcQ+5Jj37SpwAm5VDqntKcMJE1ZJZ2nsabxmnHphsq57Zb6YUbjxPZ0es0tfOmI1Z39nOqyvZFF6BINKyHPX8d8j/ledQmf4ZUq7gxxsLmqqmVYJoevd5ZCCmkTQk= Received: from DUZPR01CA0020.eurprd01.prod.exchangelabs.com (2603:10a6:10:46b::16) by AS4PR08MB7602.eurprd08.prod.outlook.com (2603:10a6:20b:4cc::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.26; Tue, 24 Jun 2025 08:06:23 +0000 Received: from DU2PEPF00028CFC.eurprd03.prod.outlook.com (2603:10a6:10:46b:cafe::98) by DUZPR01CA0020.outlook.office365.com (2603:10a6:10:46b::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.31 via Frontend Transport; Tue, 24 Jun 2025 08:06:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU2PEPF00028CFC.mail.protection.outlook.com (10.167.242.180) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 08:06:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FNZocgo8H9oDz/0ab/w6hj3i3FolrMs+TyS9gSUZKaY66fjiXWObcrG7oqJxUcs6M35mnxqNk+rdZCTijAaEtYGWReczCXbBLJlGw8G1tgBfCiAtmwQjptLKf6v8MVSMfs6iglI1V1t16ayu9AROMQrIxWvTPOJvtilg96PtKANhEi/Ga3tEJpOq34fdSqtkd2oai9pJDFf3tjH6TEZsgLVa7CULNYy4AYP7W0Lw8lmsewhi4Ugx7u4bRLAF3/Ick1kE7NjKMhTjLfnWF/v2UHVaHYhsTt3EZ6KI1VwKHToEs4S+5Q9irz94CEq35/GLd6yfecb+JY1NckFRnDR2NA== 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=lQxyQ5iy77ih4OPBvSCcFxyNinYVT9OPL5tD3c5pQyU=; b=Pahraa7ou4wLDujkwcTTMgrQ4edEFfik5CfFe/x/KZXaJYcsuSUlF2P/8s16qXd9S1bmeyiJq5mim+BMalDdCOxKcK/l5F47UTy+n31qsiExzmnkwavqK7WxdbolTFgUKy8lnFp//A48yT8OWSCaN9ucJczJyzQK3XhmpR0hiV+dw2aVKFBa7JxGTk8C6GP8QlTdj0TKFtsCHEwqc3uorTnl1/yiQ40K9ghYcOvpnnbUYc3Ta0AJ/PEFpjxQcixczOxlRivD3RkQpbQoTv8eqR6ABBTgVH1VFUiHUWh/O22da9i/35MfR2mioygfJJxUCpXTERvdd6d1nGI4eB33Qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQxyQ5iy77ih4OPBvSCcFxyNinYVT9OPL5tD3c5pQyU=; b=U1Ji07c15cyrrEgnrsxwlEUOqICKbPivHfL5k+ccZp9K1XGcQ+5Jj37SpwAm5VDqntKcMJE1ZJZ2nsabxmnHphsq57Zb6YUbjxPZ0es0tfOmI1Z39nOqyvZFF6BINKyHPX8d8j/ledQmf4ZUq7gxxsLmqqmVYJoevd5ZCCmkTQk= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) by AM8PR08MB6323.eurprd08.prod.outlook.com (2603:10a6:20b:354::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.16; Tue, 24 Jun 2025 08:05:51 +0000 Received: from PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d]) by PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d%6]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025 08:05:50 +0000 Message-ID: Date: Tue, 24 Jun 2025 09:05:49 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 11/11] gdb: Enable displaced stepping with shadow stack on amd64 linux. To: "Schimpe, Christina" , "gdb-patches@sourceware.org" Cc: "thiago.bauermann@linaro.org" , "eliz@gnu.org" References: <20250617121147.1956686-1-christina.schimpe@intel.com> <20250617121147.1956686-12-christina.schimpe@intel.com> <5c1dfebf-dc18-4193-9542-ab875966d15a@arm.com> Content-Language: en-US From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO3P123CA0025.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:388::14) To PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: PR3PR08MB5852:EE_|AM8PR08MB6323:EE_|DU2PEPF00028CFC:EE_|AS4PR08MB7602:EE_ X-MS-Office365-Filtering-Correlation-Id: bfa7459d-7266-487f-75db-08ddb2f6025b x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?UG5uVFd1YUVOaXJkSXNMZ1pTUXJmZkJWM2dxNUdyWnBkb29XR1BuRWNCV3pm?= =?utf-8?B?RWZmRENRTi9NbGsxRWpRbGV4ditSRVpzQTA3cXZaQS9aRTlsam5FM2RBanhs?= =?utf-8?B?VUYvWHFrMlcrWFpPS0I3dWcwU0dWQXpMUHdVMzd1TkVidlBzRGpRbTNIY05y?= =?utf-8?B?QW5tZXZRbWlmMWRjMnJGUlJ4ZXVKUU56c3FUOURTUVRWejV4S2hEaUJGeCtp?= =?utf-8?B?NFhzRFp2MDJWNk5PUXo5RXJ6RkU5YTRubFVYNjdNOFI0ZVhkZ05LSDgzMlcy?= =?utf-8?B?cVJESHM2OFRWakFDMXJoQjU2NXBGQWh4YUdvUkNzQm1QY0N5dncxbzZOZ25q?= =?utf-8?B?cUlkeTgvUmg5T1N5eEF2NGMyRTNrVXV2dlhWQTRERTRpbDdpU3ZtL3Q4ZTZH?= =?utf-8?B?NmZ3Z1NuSWFUU1N4QlZKQWg3cGlrSXRWd05SNkk1T2dHdDFWVWVTcDJPMWw4?= =?utf-8?B?MzBjWm1lcnZYeWxqVGYyRm5scktqd241TlpXalh1N1VVT29YNkRjWDRiQ2Fj?= =?utf-8?B?Z0I4WVUxd0FQcnkySitpakRCbkQ1STRnMW0rcUxkZUFVaVNIVXY1RGNGMllZ?= =?utf-8?B?U2EzWEk2bG9oUFR6RmRGWkVqejlKM0ZRcndrVDRMOTkwTC82a2R1UkxRZlRZ?= =?utf-8?B?b0FCTTcwV1BwdjIzRkwwUkttUllsaHhuSzlMZWN6NktTYi92Y3cyaFVLRWQ2?= =?utf-8?B?S2VUWXV2MHNLMjZWeVZVMnJRTWI1eDNhQkVvVHR0ZS8wdFZFZ3h2TGF1NXJw?= =?utf-8?B?VHhCWmhSOVAybDNUMXlaRnJLc1ZReUU2VlFtcXF6MHZkOHhOYWVoRi90eDdW?= =?utf-8?B?OUxkQzRmY1E5K3pCM3Fxb0hVMzBnZ0hRcTlUMmlrcFU5UHFKbTRzeXhCSnJL?= =?utf-8?B?VTVTZW1uMmI0QzJvY3IzWlp3UkdJOGJCcWdQSjJGcy9sVG5MUzFTSElxQ0ta?= =?utf-8?B?NEJHakJDVGhPRk9IenUrZko5WUdtNVgyMTk3RlQyaVM5UGl4TXA5MVAwd0dG?= =?utf-8?B?SDZYckI4Mmg1czAwNzZHZEZuVE8wVndkYmhqZnBHMC90WTVQMzJDeXBTRnZn?= =?utf-8?B?QVh3Uk4vbEQxMHhLcHZMNVR6aExUTklJRmJjUEI3eVlweE90VVNIMlJHMDFE?= =?utf-8?B?TGI4aGdwQ3UvNXdnOVU2Y2d0YXBFdWh0TFVCTmRrckpIc0VXUGpDcjRRT3dk?= =?utf-8?B?MGxVV0VybHozaml1YUhETkFLR0FUekpob2M2Qzl0SVdUV1Z1S1Z6SUVEd0g3?= =?utf-8?B?SWROZ3p4YUExdXF5d2lRbU9RWFAxNFIrbWIyYWNCOG4yazFabXFGRnZvaXNY?= =?utf-8?B?bDlxbmtYUmdYVDZMT3ZTcGlGSTRiMTVqUFozRkprRnRTMTN5bklOaERpUThR?= =?utf-8?B?RXcxUjcwNXdSblpRV09JOW1WRWtEQ0xQQWpiaUpZZkI3MDJMYXlIMmpKa3Jr?= =?utf-8?B?SVMzOVRvNk92dlBvUzJUem1PVS85WDRzdHlxb0Y4aDhCd08zUEhMQWZFdTZx?= =?utf-8?B?WUpzclVNTEdZajBYZmoyNUdWNDAyT0hvY3R5dnJUYkd5YXAyOVBJSTB6Ylgv?= =?utf-8?B?VE9iWCtUVXJKa3BKNUIwTUFEMC9XUU5aMU1IWmlRM3ZBN2JzSTc5TU0zcWky?= =?utf-8?B?TjhHL3hkRW5UT3Rhb1ZselJFM2twZGZsZkdCL0RQMlFINk51NVZlK25ha0Yw?= =?utf-8?B?aUJ6VGxzUjZYZ3o3SUg5QW05M2ZtYVNadkI4N0RxSDlEQXhqUnhROW1DNWc3?= =?utf-8?B?NWU2R0U4VndXR255YmVRUCswMG01ZUw5Wm1oVS9BMVVaNEtjVGJvbHBPUHpq?= =?utf-8?Q?qVGehByPUTlNWpTKOuM3TvXUC7J6EVOmgCyOI=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR08MB5852.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(7053199007); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6323 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028CFC.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d1cc31c9-c988-4bdf-d0bb-08ddb2f5ef27 X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700013|1800799024|376014|82310400026|14060799003|35042699022|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YXkrZ1RjSlVXbmpIZHZRMkVQdjBHdFMyRVVLaDVvZ2pjSFlYK3BUVHlJK0lQ?= =?utf-8?B?WUk3WkVBRklYR0IzeHJQUWRNWXVuQkVCaVlnbHFRYnUxWWxNMjk5NTlzYnBv?= =?utf-8?B?Z1JIZzdKRG9RYW0yNXNHZG0rTk9rQWVsSzltNVRGbm5OZHNQSTNRNTBLUm5B?= =?utf-8?B?NkNFMlJnaUhSWFphVERUYUdGOTJZUFFCM1hYblFoSjlab1pFUUoyTzBsaFVq?= =?utf-8?B?Wkx1RVRwcEhtNlBrQVJydTI4YjZueklMNFFpbkdPZjRlRUp5TXdic3I2TFlK?= =?utf-8?B?ek4wdkwzdnRjWUo0YlBEN1FhUEMvRnExdmE1YmMzSlh1Mm1BZFpDbWNOemx0?= =?utf-8?B?UXdLTEZIcks2UlhteDQyOE96TTh2emhWZSs3R1o0L3FKSkpnUHBoSG9meGxL?= =?utf-8?B?N3JBd05rTThrVHdsdTJITHBDdVFpUFVySEo2b0NXZnNQeU5ucjRJRUhscFRN?= =?utf-8?B?d0V0UWl3TFdXc3VpQ1ZRTzQ4YVF6SEZSSHo2by9UM1M5S2tXakE4UWY5eHdn?= =?utf-8?B?blNQZ1RsOWlCcS92Nm5waS8yQndNSVcyNDUzbmJJcjVyTUgyU096NlJPMTd0?= =?utf-8?B?VS96WWg4U3dTUG96d1NJYldKR2FpUTVOTmlYOEVkS0MvaHVSekNLaFR0Ykp3?= =?utf-8?B?MDNVTW9FZytkaDdNZEU5SW8zYjVSZGppK2dUcFVoMnhvbElpOWJtekhaN1RD?= =?utf-8?B?bXRQVGl4cVFKeHRxVVVhREs2Ni9SMG44N0JTejNSa0FhRmFoR2tGQkNwMHpQ?= =?utf-8?B?bWFObjNnMjlhUm9jQmJ4ejVSaHEzVnY5dExmVC9EVTYzaUthbThiOHViMk1r?= =?utf-8?B?Sy9LT0tHMFdLVlRNRGZhcWYwdU1FTklTZ1AyYXc5dS9NT3JSNWFGTVh3L1Rq?= =?utf-8?B?Y3dPc3Y3V1NzS1ZYWnp1aGtHWGpHdXlhVzlXUmtpcVhaMjJuYnFZSnA5ZFo4?= =?utf-8?B?MWxEZW9LK3lSUzh6aWlHNzN1ZGkyc09oM201YmtETnR4c2Y3cVc4NU1WQjli?= =?utf-8?B?ZzllOTIwQnlTQ1MvaUUzVFpzUFEySEpGQVlwR1lIazZhVXFidTROb2Z0Sm84?= =?utf-8?B?OHp0SjRvTUVzcEVSOU4yUWt4L0NyKzBwa0dtci8rVCtZVGwzUHdaNi9yNHFI?= =?utf-8?B?clBMWFlMR045MXpjYmdvWmF5bndqU0pDTVhMNk9Qd09pa1JucUsxYkVTQUpK?= =?utf-8?B?TnRNK2FzeGRxanEyK2E2ZzArd1BFVTNEN0lFR3pBSkN6QndFalNCNmY2OHBL?= =?utf-8?B?VXZ1THp2ditxc2lsZUxuUEYrSCtJVUJNL0V3cEJrOGx3NmdZNGF5anFWeE00?= =?utf-8?B?b0ZMc01xVXZ0dHc0WllIcG5NQ0lmMVhqM0lpeUZCTFNqVEJtOE9hNisweU9T?= =?utf-8?B?RkRkR3h5K28zMUE3bmpxblFYV2VyZXFmcCszZ1duUVR2Szk1R3M4ajA3OEYr?= =?utf-8?B?UEF3aHNMQ2ZUeEhOa05lcDNWaWQwWVJUbCt2TzBZakVxclVtREFBM2w1dUZy?= =?utf-8?B?Qk8wUUdobGU4MEFTVmhqSjAxSGRqYlJxckljY2IzSFNkM2VsR04zSnpiSzFC?= =?utf-8?B?NjdaeXAwWmlpZi9FNjM1U2RXeU9pQUc1MDh1MXVaVXpKdTNuVVpQL2NNWDZu?= =?utf-8?B?ZjBPWitEZTRFbURlOFVJTHBMclBnZUkyUVhEZFBpd0FlT3BYYWdhSEpyQXF6?= =?utf-8?B?aGdCdFRoUVFwbmhFb0xZYXpGUEQ5NzFzbnM0WDBINUFPMWlTc2kzUDdqN2Ru?= =?utf-8?B?VzVPNENWZjEzd1FDNmZnU290TUZYQU95SmtVemsrU25FQ3dIMDFhUEUrbEI4?= =?utf-8?B?TXZrQ2JFWlU5c3RnZmVJd3k4VjJMTlJ4dFhKWVh0ck9Ndk9aLzRnQ1B1dExQ?= =?utf-8?B?T252R0ZPZ0VUSDZ0VkRIUitFNTlPYm5Vc0IyRWtYcVVCVVRTVlRxRm8vSkI4?= =?utf-8?B?Q2pOazNlTVFwTnNRUy9yWURYcTlLbm9OcWZESDhPTnhVbE9aVXNiYWZjQitt?= =?utf-8?B?VFRuZG1UdVd3PT0=?= X-Forefront-Antispam-Report: CIP:4.158.2.129; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:outbound-uk1.az.dlp.m.darktrace.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(14060799003)(35042699022)(7053199007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 08:06:22.6697 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bfa7459d-7266-487f-75db-08ddb2f6025b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[4.158.2.129]; Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028CFC.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7602 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 On 6/23/25 19:24, Schimpe, Christina wrote: > Hi Luis, > > Please find my comments below. > >> -----Original Message----- >> From: Luis Machado >> Sent: Thursday, June 19, 2025 11:27 AM >> To: Schimpe, Christina ; gdb- >> patches@sourceware.org >> Cc: thiago.bauermann@linaro.org; eliz@gnu.org >> Subject: Re: [PATCH v4 11/11] gdb: Enable displaced stepping with shadow stack >> on amd64 linux. >> >> On 6/17/25 13:11, Christina Schimpe wrote: >>> This patch enables displaced stepping to support Intel's Control-Flow >>> Enforcement Technology (CET), which provides the shadow stack feature >>> for the x86 architecture. >>> Following the restriction of the linux kernel, enable displaced >>> stepping for amd64 only. >>> >>> If displaced stepping is active and the single stepped instruction is >>> a call instruction, the return address atop the stack is the address >>> following the copied instruction. However, to allow normal program >>> execution it has to be the address following the original instruction. >>> Due to that reason, the return address is corrected in >>> amd64_displaced_step_fixup and i386_displaced_step_fixup. >> >> I thought the description was slightly confusing. The above is the original >> behavior, right? > > Yes. > >>> >>> To avoid a control-protection exception if shadow stack is active, the >>> shadow stack top address must be corrected as well. >> >> And this one is the new behavior? >> >> Might make sense to clarify it. > > I agree, does this sound better? > > [...], enable displaced stepping for amd64 only. > > Currently, if displaced stepping is active and the single stepped instruction is > a call instruction, the return address atop the stack is the address following > the copied instruction. However, to allow normal program execution it has > to be the address following the original instruction. Due to that reason, > the return address is corrected in amd64_displaced_step_fixup and > i386_displaced_step_fixup. > > For programs that are shadow-stack enabled we see a control-protection > exception, as the address on the shadow stack does not match the address > atop the stack. > > Fix this by correcting the shadow stack top address as well. > That makes it better. Thanks! >> >>> >>> Reviewed-By: Eli Zaretskii >>> --- >>> gdb/NEWS | 3 + >>> gdb/amd64-linux-tdep.c | 16 +++- >>> gdb/amd64-tdep.c | 15 ++++ >>> gdb/doc/gdb.texinfo | 11 ++- >>> gdb/i386-tdep.c | 15 ++++ >>> .../gdb.arch/amd64-shadow-stack-disp-step.exp | 90 >>> +++++++++++++++++++ >>> 6 files changed, 147 insertions(+), 3 deletions(-) create mode >>> 100644 gdb/testsuite/gdb.arch/amd64-shadow-stack-disp-step.exp >>> >>> diff --git a/gdb/NEWS b/gdb/NEWS >>> index b8fb7f0e484..15d2772230e 100644 >>> --- a/gdb/NEWS >>> +++ b/gdb/NEWS >>> @@ -3,6 +3,9 @@ >>> >>> *** Changes since GDB 16 >>> >>> +* Debugging Linux programs that use x86-64 or x86-64 with 32-bit >>> +pointer >>> + size (X32) Shadow Stacks are now supported. >> >> Should we mention CET somewhere? > > Hm, in theory, this should work for AMD64 in general. But I don't know about > the state of AMD's shadow stack and am not sure how I could explain this in the > NEWS properly. > Alright. This is OK then. >> >>> + >>> * Support for the shadow stack pointer register on x86-64 or x86-64 with >>> 32-bit pointer size (X32) GNU/Linux. >>> >>> diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c index >>> d847248659a..f989cfb3bf8 100644 >>> --- a/gdb/amd64-linux-tdep.c >>> +++ b/gdb/amd64-linux-tdep.c >>> @@ -1935,8 +1935,10 @@ >> amd64_linux_shadow_stack_element_size_aligned (gdbarch *gdbarch) >>> possible. */ >>> >>> static std::optional >>> -amd64_linux_get_shadow_stack_pointer (gdbarch *gdbarch, regcache >>> *regcache) >>> +amd64_linux_get_shadow_stack_pointer (gdbarch *gdbarch, regcache >> *regcache, >>> + bool &shadow_stack_enabled) >>> { >>> + shadow_stack_enabled = false; >>> const i386_gdbarch_tdep *tdep = gdbarch_tdep >>> (gdbarch); >>> >>> if (tdep == nullptr || tdep->ssp_regnum < 0) @@ -1954,6 +1956,9 @@ >>> amd64_linux_get_shadow_stack_pointer (gdbarch *gdbarch, regcache >> *regcache) >>> if (ssp == 0x0) >>> return {}; >>> >>> + /* In case there is a shadow stack pointer available which is non-null, >>> + the shadow stack feature is enabled. */ shadow_stack_enabled = >>> + true; >>> return ssp; >>> } >>> >>> @@ -1964,8 +1969,13 @@ static void >>> amd64_linux_shadow_stack_push (gdbarch *gdbarch, CORE_ADDR >> new_addr, >>> regcache *regcache) >>> { >>> + bool shadow_stack_enabled; >>> std::optional ssp >>> - = amd64_linux_get_shadow_stack_pointer (gdbarch, regcache); >>> + = amd64_linux_get_shadow_stack_pointer (gdbarch, regcache, >>> + shadow_stack_enabled); >>> + >>> + /* It's enough to check if SSP is valid as for amd64 linux shadow stack >>> + is always enabled if SSP has a value. */ >> >> Is my understanding correct that for amd64's shadow stack support, whenever >> SSP has a value, then shadow stack is enabled? > > Yes, exactly. > >> >> If so, maybe rephrase it as... >> >> "For amd64/Linux, if SSP has a value that means shadow stack is enabled." >> >> What do you think? > > Yes, this makes it clearer. Thank you. > >>> if (!ssp.has_value ()) >>> return; >>> >>> @@ -2121,6 +2131,8 @@ amd64_linux_init_abi_common(struct >> gdbarch_info info, struct gdbarch *gdbarch, >>> (gdbarch, amd64_linux_remove_non_address_bits_watchpoint); >>> >>> set_gdbarch_shadow_stack_push (gdbarch, >>> amd64_linux_shadow_stack_push); >>> + set_gdbarch_get_shadow_stack_pointer (gdbarch, >>> + >> amd64_linux_get_shadow_stack_pointer); >>> dwarf2_frame_set_init_reg (gdbarch, amd64_init_reg); } >>> >>> diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c index >>> 79f7e427841..6c54957ae75 100644 >>> --- a/gdb/amd64-tdep.c >>> +++ b/gdb/amd64-tdep.c >>> @@ -1917,6 +1917,21 @@ amd64_displaced_step_fixup (struct gdbarch >> *gdbarch, >>> displaced_debug_printf ("relocated return addr at %s to %s", >>> paddress (gdbarch, rsp), >>> paddress (gdbarch, retaddr)); >>> + >>> + /* If shadow stack is enabled, we need to correct the return address >>> + on the shadow stack too. */ >>> + bool shadow_stack_enabled; >>> + std::optional ssp >>> + = gdbarch_get_shadow_stack_pointer (gdbarch, regs, >>> + shadow_stack_enabled); >>> + if (ssp.has_value () && shadow_stack_enabled) >>> + { >>> + write_memory_unsigned_integer (*ssp, retaddr_len, byte_order, >>> + retaddr); >>> + displaced_debug_printf ("relocated shadow stack return addr at %s " >>> + "to %s", paddress (gdbarch, *ssp), >>> + paddress (gdbarch, retaddr)); >>> + } >>> } >>> } >>> >>> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index >>> cf152bd1e6f..589fd50345f 100644 >>> --- a/gdb/doc/gdb.texinfo >>> +++ b/gdb/doc/gdb.texinfo >>> @@ -27055,12 +27055,20 @@ the program stream must be an >> @code{ENDBR} >>> instruction, otherwise the processor signals a control protection exception. >>> @end itemize >>> >>> -Impact on Call/Print: >>> +Impact on GDB commands: >>> +@itemize @bullet >>> +@item Call/Print: >>> Inferior calls in @value{GDBN} reset the current PC to the beginning >>> of the function that is called. No call instruction is executed, but >>> the @code{RET} instruction actually is. To avoid a control >>> protection exception due to the missing return address on the shadow >>> stack, @value{GDBN} pushes the new return address to the shadow stack and >> updates the shadow stack pointer. >>> +@item Step: >>> +With displaced stepping, @value{GDBN} may run an out of line copy of >>> +a call instruction. In this case, the wrong return address is pushed >>> +on the shadow >> >> s/pushed on/pushed to > > Will fix. > >> >>> +stack. @value{GDBN} corrects this value to avoid a control >>> +protection exception. For more details on displaced stepping, see >> @ref{displaced-stepping}. >>> +@end itemize >>> >>> @node Alpha >>> @subsection Alpha >>> @@ -41736,6 +41744,7 @@ GLOBAL Disassembler_2 (Matches >> current architecture) >>> @cindex out-of-line single-stepping >>> @item set displaced-stepping >>> @itemx show displaced-stepping >>> +@anchor{displaced-stepping} >>> Control whether or not @value{GDBN} will do @dfn{displaced stepping} >>> if the target supports it. Displaced stepping is a way to single-step >>> over breakpoints without removing them from the inferior, by executing >>> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index >>> f3fa4e511e6..d83fdc0c85e 100644 >>> --- a/gdb/i386-tdep.c >>> +++ b/gdb/i386-tdep.c >>> @@ -899,6 +899,21 @@ i386_displaced_step_fixup (struct gdbarch *gdbarch, >>> displaced_debug_printf ("relocated return addr at %s to %s", >>> paddress (gdbarch, esp), >>> paddress (gdbarch, retaddr)); >>> + >>> + /* If shadow stack is enabled, we need to correct the return address >>> + on the shadow stack too. */ >>> + bool shadow_stack_enabled; >>> + std::optional ssp >>> + = gdbarch_get_shadow_stack_pointer (gdbarch, regs, >>> + shadow_stack_enabled); >>> + if (ssp.has_value () && shadow_stack_enabled) >>> + { >>> + write_memory_unsigned_integer (*ssp, retaddr_len, byte_order, >>> + retaddr); >>> + displaced_debug_printf ("relocated shadow stack return addr at %s " >>> + "to %s", paddress (gdbarch, *ssp), >>> + paddress (gdbarch, retaddr)); >>> + } >>> } >>> } >>> >>> diff --git a/gdb/testsuite/gdb.arch/amd64-shadow-stack-disp-step.exp >>> b/gdb/testsuite/gdb.arch/amd64-shadow-stack-disp-step.exp >>> new file mode 100644 >>> index 00000000000..b5f168c2c42 >>> --- /dev/null >>> +++ b/gdb/testsuite/gdb.arch/amd64-shadow-stack-disp-step.exp >>> @@ -0,0 +1,90 @@ >>> +# Copyright 2024 Free Software Foundation, Inc. >> >> s/2024/2025 > > Will fix. > >>> + >>> +# 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 continue from call instructions with shadow stack and >>> +displaced # stepping being enabled. >>> + >>> +require allow_ssp_tests support_displaced_stepping >>> + >>> +standard_testfile amd64-shadow-stack.c >>> + >>> +save_vars { ::env(GLIBC_TUNABLES) } { >>> + >>> + append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" >>> + >>> + if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \ >>> + additional_flags="-fcf-protection=return"] } { >>> + return -1 >>> + } >>> + >>> + # Enable displaced stepping. >>> + gdb_test_no_output "set displaced-stepping on" >>> + gdb_test "show displaced-stepping" ".* displaced stepping .* is on.*" >>> + >>> + if { ![runto_main] } { >>> + return -1 >>> + } >>> + >>> + # Get the address of the call1 instruction. >>> + set call1_addr -1 >>> + gdb_test_multiple "disassemble main" "" { >>> + -re -wrap "($hex) <\\+($decimal)>:\\s*call\\s*0x.*.*" { >>> + set call1_addr $expect_out(1,string) >>> + pass $gdb_test_name >>> + } >>> + } >>> + >>> + if { $call1_addr == -1 } { >>> + return -1 >>> + } >>> + >>> + # Get the address of the call2 instruction. >>> + set call2_addr -1 >>> + gdb_test_multiple "disassemble call1" "" { >>> + -re -wrap "($hex) <\\+($decimal)>:\\s*call\\s*0x.*.*" { >>> + set call2_addr $expect_out(1,string) >>> + pass $gdb_test_name >>> + } >>> + } >>> + >>> + if { $call2_addr == -1 } { >>> + return -1 >>> + } >>> + >>> + gdb_test "break *$call1_addr" \ >>> + "Breakpoint $decimal at $hex.*" \ >>> + "break at the address of the call1 instruction" >>> + >>> + gdb_test "break *$call2_addr" \ >>> + "Breakpoint $decimal at $hex.*" \ >>> + "break at the address of the call2 instruction" >>> + >>> + # We only resume until call1 instruction in case the first instruction >>> + # we're stopped at is not yet the call1 instruction. >>> + set stop_addr [get_valueof "/x" "\$pc" "" "value of pc after runto_main"] >>> + if {[eval expr "$stop_addr < $call1_addr"]} { >>> + gdb_test "continue" \ >>> + "Breakpoint $decimal, $call1_addr in main ().*" \ >>> + "continue until call1 instruction" >>> + } >> >> It was particularly clear why we need the check above. Is this due to how the >> compiler might generate code and then we could risk stopping at the >> instruction we're interested in when we "run to main"? > > I assume you mean "It was not clear" in > "It was particularly clear why we need the check above." : Yes, sorry. I messed that one up. > > Yes, this is related to compiler behaviour. > With gcc 15 the assembler changed a bit and with "run to main" we stopped already > at the call instruction. > > I agree, the comment might be confusing. Would such a comment be better? > > # For gcc 15 we already stop at the call instruction when we "run to "main". > # Only resume in case the first instruction we're stopped at is not yet the call > # instruction. > I think it is enough to mention that depending on instruction generation we might end up in the call instruction after "runto_main". Then we don't make any references to versions, since they change in behavior sometimes. >> >>> + gdb_assert {$call1_addr == [get_valueof "/x" "\$pc" ""]} >>> + >>> + # Test continue from breakpoint at call1 and call2 instructions. >>> + gdb_test "continue" \ >>> + "Breakpoint $decimal, $call2_addr in call1 ().*" \ >>> + "continue from call1 instruction" >>> + >>> + gdb_continue_to_end "continue from call2 instruction" >>> +} >> >> Reviewed-By: Luis Machado > > Thanks for all the review efforts! > 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