Message ID | gkrh72hbhmp.fsf@arm.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:38f:b0:2d5:3c95:9e21 with SMTP id 15csp948576pxh; Fri, 12 Aug 2022 08:35:57 -0700 (PDT) X-Google-Smtp-Source: AA6agR5IcdhHjzh0BxHDfSVP63laKAgDAtiovFdMqTFnGSA0ELErVnuMDXI7MhGf0KeCRTJzHxSQ X-Received: by 2002:a17:907:2722:b0:731:201a:df9c with SMTP id d2-20020a170907272200b00731201adf9cmr3115527ejl.149.1660318556843; Fri, 12 Aug 2022 08:35:56 -0700 (PDT) Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id e20-20020a50ec94000000b0043acc275debsi2255706edr.296.2022.08.12.08.35.56 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 08:35:56 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=qTiCenJp; arc=fail (signature failed); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6738A3858427 for <ouuuleilei@gmail.com>; Fri, 12 Aug 2022 15:35:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6738A3858427 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1660318555; bh=9t269f46Y+plvlMcbyL4ejBZPynUGRn4gchqewmnbyw=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=qTiCenJpXqz9hvXjxN8sH27RzKc8HZmosfnSI3KCiB7aIi2yMy59gDd5QjKWU/bt4 dxoc+1UmBDsKPCIB2qKh3J9djIipkTzIds3DaRrbyULxvzd44n38gTmDE7lUe575mV 9oIsfYhqJs9Kasm53X5Bfujxk5LUmPVJ8XJE1rEU= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.88]) by sourceware.org (Postfix) with ESMTPS id D952C3858D28 for <gcc-patches@gcc.gnu.org>; Fri, 12 Aug 2022 15:35:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D952C3858D28 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=EfdvHxXCq07FhLatCKEpQi+ditRJ1tOxMTkdXsfN0zY371cGQg5BZKI8IauxRzzKoXEiVeN21fwRHs+P+TF8FxFoUb7aw4bNk0lERDmi5j4V/uG1khYXJMQ9tcuH/rMORnE7dzfdpFes7ynEfuntIeLiRxLWD+7AF8zt7w/wRAvGCnFXkSb+jCKsFk8LxsUy8EoidUiQujuhQoc+ZSOnhN0E5tjCKPZs17dzTalqCMHnphUmR9urLBjpSyB44jTiMK6gcLS8yjyCGkrqfWk4gyTIB+j16fDe9XZ40UVPOz1Bzur7pWP7Uf6c7rRBEUyT6UyPZ+bL3TU0LCm33z7gkQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=9t269f46Y+plvlMcbyL4ejBZPynUGRn4gchqewmnbyw=; b=TpGcI7SlJ/s/eR1IJgApuxCXTlD2klogx3Xg8BlahsV9B9oUXzmmdfeaTJioFdkQBeUeNECRhuld+32BauCHOi/wHqFrjPB5LzHAW2qw1LhQrHKxPSbe/l9BdvHsNd3eEcm5mQ9vwjh1RvEsDgbwhLDsSN/HKsIwmvYcQtKpwje46NZIdlLCnw4YJ7meuyeMp0aO2PT9ubQfkO8fieAvHB0kNi4rZXCjcNoPTjIMd9cNvZ4rVoOpcrn72cptB/lf48UZpCpdCtJ9YaHLFdGrc1nwszQqB5nzqMtWjsFXAdMqJRHVxW2op8urOodNqCQwqLfTj6XhcYDlYMPxcRFmMA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=gcc.gnu.org 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=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from DB8P191CA0005.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:130::15) by AM4PR08MB2675.eurprd08.prod.outlook.com (2603:10a6:205:10::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.16; Fri, 12 Aug 2022 15:35:08 +0000 Received: from DBAEUR03FT018.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:130:cafe::36) by DB8P191CA0005.outlook.office365.com (2603:10a6:10:130::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.15 via Frontend Transport; Fri, 12 Aug 2022 15:35:08 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT018.mail.protection.outlook.com (100.127.142.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.11 via Frontend Transport; Fri, 12 Aug 2022 15:35:08 +0000 Received: ("Tessian outbound fccf984e7173:v123"); Fri, 12 Aug 2022 15:35:08 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 053edd65d1845295 X-CR-MTA-TID: 64aa7808 Received: from beb77bbb28a7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A3537574-5119-4DCC-A571-CB99541AAE31.1; Fri, 12 Aug 2022 15:34:25 +0000 Received: from EUR03-DBA-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id beb77bbb28a7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Aug 2022 15:34:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G/VpK8SkklZAaiFrY95bkuyUVK2rKUXDVz7v79M2AaQmiKmq7YQ4ZKKUa2qtYcqtjPqeW421B6Rt52f+dgWPINRlI+Gd5NXiblzj1kU5dfHNm3D7BrdRtdmOI3kWpL2poMKh3yGZtTLOPoom8RuLyqrebNj0kX32vAiN6W1DC1TToMIfhFBZsbBrSGzQk+HqkBaKqwch8ojZoKnR5MmM+5ftHGcAqvhpSRc9zUF0897ilJFa36wJH8wkBKETk17xYuuF6MqPnlG6srpdgoEwy7T1rddV+Btbz9uCYl/dHLfKh/2NxaHAoUrGfrd5rBoKbJyNtv9Ku3oRwhMezgQBcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=9t269f46Y+plvlMcbyL4ejBZPynUGRn4gchqewmnbyw=; b=eloiikabncNR46/D/oxqtHtNvRAntwHvtozegVIzAbRBYTbcNGQgwIjzW2KBguMrDDBbZ+QnC/MAZ89eW3qHIOHUZeRGmnip2mlD/hLszXUy4U+OB4m9pNLhFML/T4bmeMD5NB3c/1em7hxqJaCJh4fCA8FJN+g788C7lTEQVJCEDVdrNgANo86pSmu0Ft0v4GD1goCSpPhU37rgEbGy9HaiSU3ny2GA5XFIm8zxN17xZi0kPwKqN9GLoOf8Dte97GGTMa3uUueLrxyMLePYbGmy65izV7STT+QtawsSAYVSQrccjI/LZxnsNY1ud1jCh6hxlvaREFyTDzY1HiQjqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=gcc.gnu.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none Received: from DU2PR04CA0030.eurprd04.prod.outlook.com (2603:10a6:10:3b::35) by AM6PR08MB2952.eurprd08.prod.outlook.com (2603:10a6:209:43::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.10; Fri, 12 Aug 2022 15:34:24 +0000 Received: from DBAEUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:3b:cafe::e4) by DU2PR04CA0030.outlook.office365.com (2603:10a6:10:3b::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.14 via Frontend Transport; Fri, 12 Aug 2022 15:34:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by DBAEUR03FT049.mail.protection.outlook.com (100.127.142.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5525.11 via Frontend Transport; Fri, 12 Aug 2022 15:34:23 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.9; Fri, 12 Aug 2022 15:34:23 +0000 Received: from e124257 (10.34.105.24) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.9 via Frontend Transport; Fri, 12 Aug 2022 15:34:22 +0000 To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when popping if necessary References: <gkrk07dczbq.fsf@arm.com> Date: Fri, 12 Aug 2022 17:34:22 +0200 In-Reply-To: <gkrk07dczbq.fsf@arm.com> (Andrea Corallo via Gcc-patches's message of "Fri, 12 Aug 2022 16:26:49 +0200") Message-ID: <gkrh72hbhmp.fsf@arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-EOPAttributedMessage: 1 X-MS-Office365-Filtering-Correlation-Id: fb67ae31-aef7-46e2-999f-08da7c783cdc X-MS-TrafficTypeDiagnostic: AM6PR08MB2952:EE_|DBAEUR03FT018:EE_|AM4PR08MB2675:EE_ x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: V5dbK297QTCOeDNFtw8hiDaV54IamYfu5O3xzuaSl04w3ri9xaNIHatjs+h0PzWo3GaU0zucoZPSnBd6qQjLOogRfqD0ZOsArrCQO3hVZMNgpD9DcTJ0RK+S2SET4un6zZWsIXPzaed5/lkAai/ezQOj7AC5gCPgd3CzSHypddk0jR7qzLLogI8sFMkGWS1fjR1Q/VfsM+1pXABfxtZ0PVfKfo9kp7mjypK9syuiz2N7+XAOUvFUa2GLDxxj3H+WuCAYuZEhclfWtlcQ9VnEFMA8tYcHcMMuFSsdlXrThlR10LDhBtoRMHVQpuyIJ8UopGKSyINOua/fZbrkNggWDJcfb2M80llkX/o498we03/72YF+gk5h+uPcZWxGyxu915GxXdOvXr3XY6k7Q3+cRWZP9O7l2YYw2Q8U5PZobTqRt5L1OHxShVDSl8XGOxm6WV2iZgYztBc+l3T5p6nJJgOoNVcLWAvP6ImOTYDMP+/eB/Vc16cUKQeV0b7ksKKPQWxeWi6lwk/wDJNGDhgXeweoD3lQaeQ0bvTgvZnosBdKm5Vu1cm3/f4GtYNur7KknpEQGvASZVPbDI1u+051wAgU5LPtTbJGndvus8BXnEaE+Q5jjBTO5V9yA/xbobY9lNIPmKoA6t1XGkJT5RYkelH5BSs8ZzChs8kKcXQ4IMVH27MYbHwtA26uJazll8ouokfBZ2BGLQenzH9WIHWH6nf+Z4Y1ycw6Qg+7Ln74cCMZticAySv88zpwys1JcB/bDRfuvyPHLpZuhucvCn6Lw/61baHut5k9xoe4QVWO/qar43EYQTS8Bo02tUKt5+IVXte7pXW6D0BnVBl/AqiqiA== X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230016)(4636009)(136003)(376002)(346002)(39860400002)(396003)(40470700004)(36840700001)(46966006)(6916009)(41300700001)(478600001)(54906003)(316002)(40480700001)(4326008)(82310400005)(2906002)(26005)(8676002)(40460700003)(44832011)(70206006)(70586007)(5660300002)(8936002)(235185007)(82740400003)(36756003)(36860700001)(564344004)(86362001)(426003)(81166007)(356005)(2616005)(336012)(47076005)(186003)(33964004)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 8vMOJYdS55I59Ud8uEP7uic+TlnV6/lvkIArbcErpOUSXLYbgDWLr4aJyxomKQw+NCJAntUAAS0ckARl3678TFQVum9Yb9PW6f+PBI0z/OkXZmbQqwMJZETVXxVOENBzt1Va1KgIsJU432IyUGHbhQdurazRgzdQNt82izcqA8fJDuaShJWGJUz7SH7W+XRDNHm4VsDOktzw0up73z8L0m6kP+QeMI3Xo/bJdkOCWE3lKmN29hph/+OYp+BBHpkVTNdTSAtq+vjnOuYziX+VjRMJjPPFWRw4dXFr0OcXr4D1v9e57s2G/BhNMwfnxO41Us1bYitzV2VpQLhF/rpgHhHeOz8BBoDVvx8Y/6FKClyXKbhstvEAxOoWQb/JK7TfpyV2srPpkTOH6t26X5eT/FHKmLiLVyiZRJcEtIqmcmgPCEMGoZSTHCoNI2ehBB0dirx609nzhTQLQ9hpPOJkuc4GVy9F6ZNQb2Y7w7okLR6SQRBIpaMZnyKGtxLFb4liNsckR1x9ID+0wwIS2HI6DZxtgS5MST4054V0i/5KweIYBmmlt3dX6JTUD7cpYfYRk9YFNJMp9UKQxBccbPP57F2bThBu/RIeHKGUEn0UKkBlNtq7fCdEUJwC38JX8AwHzJFcwCjM92utPjO2EA5m2siRw86ZAExna5ad6fI5GAV9uiWq7C/+UmkV89kBs8NVz8+d3zKPGiNjGOHeysGhHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2952 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT018.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 18f83e60-6c70-4b41-67a0-08da7c78224f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bUb35PLf9wTUYmUQbr02W+/cuGGdi/HflHz9XlatL+CTjfQwqAuX+fM9HWQ/ZjoeXHw0EDwmQTRuocnEt6S1l7nqUX9ZoBJcSeIzVrAotLkM9Hz8vCWJZOiFp4sGQi9LrjSDXeDY3ou7mBgkVCl3U1qTObYp9DWK1V2y1/4yla33J9RLjpQHwNp+0qb/DaUnlM75DPPuzi4eAuMP9gp8LjuEJPQSeiysjrttA7z4dvlBgOPb3AI1ziYJadt9dupA+djwcCW80cpGUQIkIH5WIXZafHx93yEu+wfmLKg+gtjx58F09o1lSHnmWAOikehNKtV3h1osockflHe+RS+omdvX2oh9/qpNwY5WlYx4IGUNDFisAZX567+MiHbrzXgA5lZ5l5xd516PAs/SVFHoJkBcn8Cc9+C2hmTdvPdoPO/B/l8L+EjillbkUOq6hIdvdfNZ8kkmrl4tIhxisp925Xlx6Qj+br/yGIJfZVDubVkk/bVWvQghxUlbEPb1Pzau2yBjAf8B02uJ4hsKOJfTPFf0BwUmlLSCSDxMO3UHYD3N18bpLfflwmLiJ5KrKauT8M1JgqwwUpSY9ifM9slRE5W6gjH4VC8Oc8sDhpqwJNfT3ol8wUzQaWtmZ7R5iwqyiGr1WDYSQ5945XCzpQ3z+mrloTtjRUMsWtebD3EvlzRsmvTpg0tSXWtfuNn+tuGvcwHhDUpIZgznBuYfI2strhA8tYTPwVHzibVBcRnmT5MAHbjRXGJCo5VOzbGnOCXc3b8Mq7l2u8cIWPm1el89O0h5qeA1XUVVO5NpZEFzOrc0r11mMbPj8FF9urez6Lvj X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230016)(4636009)(346002)(39860400002)(376002)(396003)(136003)(36840700001)(46966006)(40470700004)(336012)(2906002)(478600001)(8676002)(4326008)(70206006)(70586007)(564344004)(82740400003)(81166007)(235185007)(8936002)(44832011)(5660300002)(36860700001)(426003)(33964004)(2616005)(47076005)(86362001)(41300700001)(40460700003)(186003)(26005)(54906003)(40480700001)(6916009)(36756003)(316002)(82310400005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Aug 2022 15:35:08.5200 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb67ae31-aef7-46e2-999f-08da7c783cdc X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT018.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB2675 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Andrea Corallo <andrea.corallo@arm.com> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>, nd <nd@arm.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1740970191085413922?= X-GMAIL-MSGID: =?utf-8?q?1740970191085413922?= |
Series |
arm: Enables return address verification and branch target identification on Cortex-M
|
|
Commit Message
Andrea Corallo
Aug. 12, 2022, 3:34 p.m. UTC
Hi all, this patch enables 'arm_emit_multi_reg_pop' to set again the stack pointer as CFA reg when popping if this is necessary. /gcc/ * config/arm/arm.cc (arm_emit_multi_reg_pop): If the frame pointer was set define again the stack pointer as CFA reg when popping.
Comments
Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > Hi all, > > this patch enables 'arm_emit_multi_reg_pop' to set again the stack > pointer as CFA reg when popping if this is necessary. > > /gcc/ > > * config/arm/arm.cc (arm_emit_multi_reg_pop): If the frame pointer > was set define again the stack pointer as CFA reg when popping. Ping Andrea
Hi Andrea, > -----Original Message----- > From: Gcc-patches <gcc-patches- > bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea > Corallo via Gcc-patches > Sent: Friday, August 12, 2022 4:34 PM > To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> > Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> > Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when popping > if necessary > > Hi all, > > this patch enables 'arm_emit_multi_reg_pop' to set again the stack > pointer as CFA reg when popping if this is necessary. > From what I can tell from similar functions this is correct, but could you elaborate on why this change is needed for my understanding please? Thanks, Kyrill > /gcc/ > > * config/arm/arm.cc (arm_emit_multi_reg_pop): If the frame pointer > was set define again the stack pointer as CFA reg when popping.
Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: > Hi Andrea, > >> -----Original Message----- >> From: Gcc-patches <gcc-patches- >> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >> Corallo via Gcc-patches >> Sent: Friday, August 12, 2022 4:34 PM >> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when popping >> if necessary >> >> Hi all, >> >> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >> pointer as CFA reg when popping if this is necessary. >> > > From what I can tell from similar functions this is correct, but could you elaborate on why this change is needed for my understanding please? > Thanks, > Kyrill Hi Kyrill, sure, if the frame pointer was set, than it is the current CFA register. If we request to adjust the current CFA register offset indicating it being SP (while it's actually FP) that is indeed not correct and the incoherence we will be detected by an assertion in the dwarf emission machinery. Best Regards Andrea
> -----Original Message----- > From: Andrea Corallo <andrea.corallo@arm.com> > Sent: Tuesday, September 27, 2022 11:06 AM > To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> > Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard > Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> > Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when > popping if necessary > > Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: > > > Hi Andrea, > > > >> -----Original Message----- > >> From: Gcc-patches <gcc-patches- > >> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea > >> Corallo via Gcc-patches > >> Sent: Friday, August 12, 2022 4:34 PM > >> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> > >> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> > >> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when > popping > >> if necessary > >> > >> Hi all, > >> > >> this patch enables 'arm_emit_multi_reg_pop' to set again the stack > >> pointer as CFA reg when popping if this is necessary. > >> > > > > From what I can tell from similar functions this is correct, but could you > elaborate on why this change is needed for my understanding please? > > Thanks, > > Kyrill > > Hi Kyrill, > > sure, if the frame pointer was set, than it is the current CFA register. > If we request to adjust the current CFA register offset indicating it > being SP (while it's actually FP) that is indeed not correct and the > incoherence we will be detected by an assertion in the dwarf emission > machinery. Thanks, the patch is ok Kyrill > > Best Regards > > Andrea
On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: > > >> -----Original Message----- >> From: Andrea Corallo <andrea.corallo@arm.com> >> Sent: Tuesday, September 27, 2022 11:06 AM >> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >> popping if necessary >> >> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >> >>> Hi Andrea, >>> >>>> -----Original Message----- >>>> From: Gcc-patches <gcc-patches- >>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>> Corallo via Gcc-patches >>>> Sent: Friday, August 12, 2022 4:34 PM >>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >> popping >>>> if necessary >>>> >>>> Hi all, >>>> >>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>> pointer as CFA reg when popping if this is necessary. >>>> >>> >>> From what I can tell from similar functions this is correct, but could you >> elaborate on why this change is needed for my understanding please? >>> Thanks, >>> Kyrill >> >> Hi Kyrill, >> >> sure, if the frame pointer was set, than it is the current CFA register. >> If we request to adjust the current CFA register offset indicating it >> being SP (while it's actually FP) that is indeed not correct and the >> incoherence we will be detected by an assertion in the dwarf emission >> machinery. > > Thanks, the patch is ok > Kyrill > >> >> Best Regards >> >> Andrea Hmm, wait. Why would a multi-reg pop be updating the stack pointer? Please can you show a code sequence where this is needed. R.
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >> >>> -----Original Message----- >>> From: Andrea Corallo <andrea.corallo@arm.com> >>> Sent: Tuesday, September 27, 2022 11:06 AM >>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>> popping if necessary >>> >>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>> >>>> Hi Andrea, >>>> >>>>> -----Original Message----- >>>>> From: Gcc-patches <gcc-patches- >>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>> Corallo via Gcc-patches >>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>> popping >>>>> if necessary >>>>> >>>>> Hi all, >>>>> >>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>> pointer as CFA reg when popping if this is necessary. >>>>> >>>> >>>> From what I can tell from similar functions this is correct, but could you >>> elaborate on why this change is needed for my understanding please? >>>> Thanks, >>>> Kyrill >>> >>> Hi Kyrill, >>> >>> sure, if the frame pointer was set, than it is the current CFA register. >>> If we request to adjust the current CFA register offset indicating it >>> being SP (while it's actually FP) that is indeed not correct and the >>> incoherence we will be detected by an assertion in the dwarf emission >>> machinery. >> Thanks, the patch is ok >> Kyrill >> >>> >>> Best Regards >>> >>> Andrea > > Hmm, wait. Why would a multi-reg pop be updating the stack pointer? Hi Richard, not sure I understand, isn't any pop updating SP by definition? BR Andrea
On 26/10/2022 09:49, Andrea Corallo via Gcc-patches wrote: > Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > >> On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >>> >>>> -----Original Message----- >>>> From: Andrea Corallo <andrea.corallo@arm.com> >>>> Sent: Tuesday, September 27, 2022 11:06 AM >>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>> popping if necessary >>>> >>>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>>> >>>>> Hi Andrea, >>>>> >>>>>> -----Original Message----- >>>>>> From: Gcc-patches <gcc-patches- >>>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>>> Corallo via Gcc-patches >>>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>> popping >>>>>> if necessary >>>>>> >>>>>> Hi all, >>>>>> >>>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>>> pointer as CFA reg when popping if this is necessary. >>>>>> >>>>> >>>>> From what I can tell from similar functions this is correct, but could you >>>> elaborate on why this change is needed for my understanding please? >>>>> Thanks, >>>>> Kyrill >>>> >>>> Hi Kyrill, >>>> >>>> sure, if the frame pointer was set, than it is the current CFA register. >>>> If we request to adjust the current CFA register offset indicating it >>>> being SP (while it's actually FP) that is indeed not correct and the >>>> incoherence we will be detected by an assertion in the dwarf emission >>>> machinery. >>> Thanks, the patch is ok >>> Kyrill >>> >>>> >>>> Best Regards >>>> >>>> Andrea >> >> Hmm, wait. Why would a multi-reg pop be updating the stack pointer? > > Hi Richard, > > not sure I understand, isn't any pop updating SP by definition? Yes, but the SP must already be the CFA before this instruction, since SP must be the base of the pop. So the reg note changing the CFA to SP can't be right. I'm thinking there must be some earlier restore of SP that's missing a frame-related note. R. > > BR > > Andrea
Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > >> On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >>> >>>> -----Original Message----- >>>> From: Andrea Corallo <andrea.corallo@arm.com> >>>> Sent: Tuesday, September 27, 2022 11:06 AM >>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>> popping if necessary >>>> >>>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>>> >>>>> Hi Andrea, >>>>> >>>>>> -----Original Message----- >>>>>> From: Gcc-patches <gcc-patches- >>>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>>> Corallo via Gcc-patches >>>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>> popping >>>>>> if necessary >>>>>> >>>>>> Hi all, >>>>>> >>>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>>> pointer as CFA reg when popping if this is necessary. >>>>>> >>>>> >>>>> From what I can tell from similar functions this is correct, but could you >>>> elaborate on why this change is needed for my understanding please? >>>>> Thanks, >>>>> Kyrill >>>> >>>> Hi Kyrill, >>>> >>>> sure, if the frame pointer was set, than it is the current CFA register. >>>> If we request to adjust the current CFA register offset indicating it >>>> being SP (while it's actually FP) that is indeed not correct and the >>>> incoherence we will be detected by an assertion in the dwarf emission >>>> machinery. >>> Thanks, the patch is ok >>> Kyrill >>> >>>> >>>> Best Regards >>>> >>>> Andrea >> >> Hmm, wait. Why would a multi-reg pop be updating the stack pointer? > > Hi Richard, > > not sure I understand, isn't any pop updating SP by definition? Back on this, compiling: ======= int i; void foo (int); int bar() { foo (i); return 0; } ======= With -march=armv8.1-m.main+fp -mbranch-protection=pac-ret+leaf -mthumb -O0 -g Produces the following asm for bar. bar: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 1, uses_anonymous_args = 0 pac ip, lr, sp push {r3, r7, ip, lr} add r7, sp, #0 ldr r3, .L3 ldr r3, [r3] mov r0, r3 bl foo movs r3, #0 mov r0, r3 pop {r3, r7, ip, lr} aut ip, lr, sp bx lr The offending instruction causing the ICE (without this patch) when emitting dwarf is "pop {r3, r7, ip, lr}". The current CFA reg when emitting the multipop is R7 (the frame pointer). If is not the multipop that has the duty to restore SP as current CFA here which other instruction should do it? Best Regards Andrea
On 09/01/2023 14:58, Andrea Corallo via Gcc-patches wrote: > Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > >> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >> >>> On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >>>> >>>>> -----Original Message----- >>>>> From: Andrea Corallo <andrea.corallo@arm.com> >>>>> Sent: Tuesday, September 27, 2022 11:06 AM >>>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>>>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>>>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>>> popping if necessary >>>>> >>>>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>>>> >>>>>> Hi Andrea, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gcc-patches <gcc-patches- >>>>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>>>> Corallo via Gcc-patches >>>>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>>> popping >>>>>>> if necessary >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>>>> pointer as CFA reg when popping if this is necessary. >>>>>>> >>>>>> >>>>>> From what I can tell from similar functions this is correct, but could you >>>>> elaborate on why this change is needed for my understanding please? >>>>>> Thanks, >>>>>> Kyrill >>>>> >>>>> Hi Kyrill, >>>>> >>>>> sure, if the frame pointer was set, than it is the current CFA register. >>>>> If we request to adjust the current CFA register offset indicating it >>>>> being SP (while it's actually FP) that is indeed not correct and the >>>>> incoherence we will be detected by an assertion in the dwarf emission >>>>> machinery. >>>> Thanks, the patch is ok >>>> Kyrill >>>> >>>>> >>>>> Best Regards >>>>> >>>>> Andrea >>> >>> Hmm, wait. Why would a multi-reg pop be updating the stack pointer? >> >> Hi Richard, >> >> not sure I understand, isn't any pop updating SP by definition? > > > Back on this, > > compiling: > > ======= > int i; > > void foo (int); > > int bar() > { > foo (i); > return 0; > } > ======= > > With -march=armv8.1-m.main+fp -mbranch-protection=pac-ret+leaf -mthumb -O0 -g > > Produces the following asm for bar. > > bar: > @ args = 0, pretend = 0, frame = 0 > @ frame_needed = 1, uses_anonymous_args = 0 > pac ip, lr, sp > push {r3, r7, ip, lr} > add r7, sp, #0 > ldr r3, .L3 > ldr r3, [r3] > mov r0, r3 > bl foo > movs r3, #0 > mov r0, r3 > pop {r3, r7, ip, lr} > aut ip, lr, sp > bx lr > > The offending instruction causing the ICE (without this patch) when > emitting dwarf is "pop {r3, r7, ip, lr}". > > The current CFA reg when emitting the multipop is R7 (the frame > pointer). If is not the multipop that has the duty to restore SP as > current CFA here which other instruction should do it? Ah, OK. I think this is a special case, though, because in this specific case the frame pointer (r7) and the stack pointer point to the same place. This means that in the epilogue we don't start by restoring SP from FP (at which point we tell the dwarf code that the frame is back in SP again). For example, if I have: int i; void foo (int, int*); int bar() { int j[10]; foo (i,j); return 0; } then the epilogue sequence starts with: adds r7, r7, #40 .cfi_def_cfa_offset 8 mov sp, r7 .cfi_def_cfa_register 13 And then the pop works correctly as-is. But I'm not convinced that this is enough anyway, you cause the compiler to output a directive that changes the CFA pointer back to r13, but you don't output anything that changes the CFA offset. So I think this means that the CFA state machine ends up pointing to the wrong location, but it's hard to tell as you haven't shown the CFA directives in your example above. > > Best Regards > > Andrea R.
On 09/01/2023 14:58, Andrea Corallo via Gcc-patches wrote: > Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > >> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >> >>> On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >>>> >>>>> -----Original Message----- >>>>> From: Andrea Corallo <andrea.corallo@arm.com> >>>>> Sent: Tuesday, September 27, 2022 11:06 AM >>>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>>>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>>>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>>> popping if necessary >>>>> >>>>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>>>> >>>>>> Hi Andrea, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gcc-patches <gcc-patches- >>>>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>>>> Corallo via Gcc-patches >>>>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>>> popping >>>>>>> if necessary >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>>>> pointer as CFA reg when popping if this is necessary. >>>>>>> >>>>>> >>>>>> From what I can tell from similar functions this is correct, but could you >>>>> elaborate on why this change is needed for my understanding please? >>>>>> Thanks, >>>>>> Kyrill >>>>> >>>>> Hi Kyrill, >>>>> >>>>> sure, if the frame pointer was set, than it is the current CFA register. >>>>> If we request to adjust the current CFA register offset indicating it >>>>> being SP (while it's actually FP) that is indeed not correct and the >>>>> incoherence we will be detected by an assertion in the dwarf emission >>>>> machinery. >>>> Thanks, the patch is ok >>>> Kyrill >>>> >>>>> >>>>> Best Regards >>>>> >>>>> Andrea >>> >>> Hmm, wait. Why would a multi-reg pop be updating the stack pointer? >> >> Hi Richard, >> >> not sure I understand, isn't any pop updating SP by definition? > > > Back on this, > > compiling: > > ======= > int i; > > void foo (int); > > int bar() > { > foo (i); > return 0; > } > ======= > > With -march=armv8.1-m.main+fp -mbranch-protection=pac-ret+leaf -mthumb -O0 -g > > Produces the following asm for bar. > > bar: > @ args = 0, pretend = 0, frame = 0 > @ frame_needed = 1, uses_anonymous_args = 0 > pac ip, lr, sp > push {r3, r7, ip, lr} > add r7, sp, #0 > ldr r3, .L3 > ldr r3, [r3] > mov r0, r3 > bl foo > movs r3, #0 > mov r0, r3 > pop {r3, r7, ip, lr} > aut ip, lr, sp > bx lr > > The offending instruction causing the ICE (without this patch) when > emitting dwarf is "pop {r3, r7, ip, lr}". > > The current CFA reg when emitting the multipop is R7 (the frame > pointer). If is not the multipop that has the duty to restore SP as > current CFA here which other instruction should do it? > Digging a bit deeper, I'm now even more confused. arm_expand_epilogue contains (parphrasing the code): if frame_pointer_needed { if arm {} else { if adjust r7 += adjust mov sp, r7 // Reset CFA to SP } } so there should always be a move of r7 into SP, even if this is strictly redundant. I don't understand why this doesn't happen for your testcase. Can you dig a bit deeper? I wonder if we've (probably incorrectly) assumed that this function doesn't need an epilogue but can use a simple return? I don't think we should do that when authentication is needed: a simple return should really be one instruction. > Best Regards > > Andrea R.
On 09/01/2023 16:48, Richard Earnshaw via Gcc-patches wrote: > > > On 09/01/2023 14:58, Andrea Corallo via Gcc-patches wrote: >> Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> >>> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >>> >>>> On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >>>>> >>>>>> -----Original Message----- >>>>>> From: Andrea Corallo <andrea.corallo@arm.com> >>>>>> Sent: Tuesday, September 27, 2022 11:06 AM >>>>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>>>>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>>>>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg >>>>>> when >>>>>> popping if necessary >>>>>> >>>>>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>>>>> >>>>>>> Hi Andrea, >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Gcc-patches <gcc-patches- >>>>>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>>>>> Corallo via Gcc-patches >>>>>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>>>> popping >>>>>>>> if necessary >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>>>>> pointer as CFA reg when popping if this is necessary. >>>>>>>> >>>>>>> >>>>>>> From what I can tell from similar functions this is correct, >>>>>>> but could you >>>>>> elaborate on why this change is needed for my understanding please? >>>>>>> Thanks, >>>>>>> Kyrill >>>>>> >>>>>> Hi Kyrill, >>>>>> >>>>>> sure, if the frame pointer was set, than it is the current CFA >>>>>> register. >>>>>> If we request to adjust the current CFA register offset indicating it >>>>>> being SP (while it's actually FP) that is indeed not correct and the >>>>>> incoherence we will be detected by an assertion in the dwarf emission >>>>>> machinery. >>>>> Thanks, the patch is ok >>>>> Kyrill >>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Andrea >>>> >>>> Hmm, wait. Why would a multi-reg pop be updating the stack pointer? >>> >>> Hi Richard, >>> >>> not sure I understand, isn't any pop updating SP by definition? >> >> >> Back on this, >> >> compiling: >> >> ======= >> int i; >> >> void foo (int); >> >> int bar() >> { >> foo (i); >> return 0; >> } >> ======= >> >> With -march=armv8.1-m.main+fp -mbranch-protection=pac-ret+leaf -mthumb >> -O0 -g >> >> Produces the following asm for bar. >> >> bar: >> @ args = 0, pretend = 0, frame = 0 >> @ frame_needed = 1, uses_anonymous_args = 0 >> pac ip, lr, sp >> push {r3, r7, ip, lr} >> add r7, sp, #0 >> ldr r3, .L3 >> ldr r3, [r3] >> mov r0, r3 >> bl foo >> movs r3, #0 >> mov r0, r3 >> pop {r3, r7, ip, lr} >> aut ip, lr, sp >> bx lr >> >> The offending instruction causing the ICE (without this patch) when >> emitting dwarf is "pop {r3, r7, ip, lr}". >> >> The current CFA reg when emitting the multipop is R7 (the frame >> pointer). If is not the multipop that has the duty to restore SP as >> current CFA here which other instruction should do it? >> > > Digging a bit deeper, I'm now even more confused. arm_expand_epilogue > contains (parphrasing the code): > > if frame_pointer_needed > { > if arm > {} > else > { > if adjust > r7 += adjust > mov sp, r7 // Reset CFA to SP > } > } > > so there should always be a move of r7 into SP, even if this is strictly > redundant. I don't understand why this doesn't happen for your > testcase. Can you dig a bit deeper? I wonder if we've (probably > incorrectly) assumed that this function doesn't need an epilogue but can > use a simple return? I don't think we should do that when > authentication is needed: a simple return should really be one instruction. > So I strongly suspect the real problem here is that use_return_insn () in arm.cc needs to be updated to return false when using pointer authentication. The specification for this function says that a return can be done in one instruction; and clearly when we need authentication more than one is needed. R. >> Best Regards >> >> Andrea > > R.
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > On 09/01/2023 16:48, Richard Earnshaw via Gcc-patches wrote: >> On 09/01/2023 14:58, Andrea Corallo via Gcc-patches wrote: >>> Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>> >>>> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >>>> >>>>> On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Andrea Corallo <andrea.corallo@arm.com> >>>>>>> Sent: Tuesday, September 27, 2022 11:06 AM >>>>>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >>>>>>> Cc: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org>; Richard >>>>>>> Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>>> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA >>>>>>> reg when >>>>>>> popping if necessary >>>>>>> >>>>>>> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes: >>>>>>> >>>>>>>> Hi Andrea, >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Gcc-patches <gcc-patches- >>>>>>>>> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Andrea >>>>>>>>> Corallo via Gcc-patches >>>>>>>>> Sent: Friday, August 12, 2022 4:34 PM >>>>>>>>> To: Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> >>>>>>>>> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>; nd <nd@arm.com> >>>>>>>>> Subject: [PATCH 9/15] arm: Set again stack pointer as CFA reg when >>>>>>> popping >>>>>>>>> if necessary >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> this patch enables 'arm_emit_multi_reg_pop' to set again the stack >>>>>>>>> pointer as CFA reg when popping if this is necessary. >>>>>>>>> >>>>>>>> >>>>>>>> From what I can tell from similar functions this is correct, >>>>>>>> but could you >>>>>>> elaborate on why this change is needed for my understanding please? >>>>>>>> Thanks, >>>>>>>> Kyrill >>>>>>> >>>>>>> Hi Kyrill, >>>>>>> >>>>>>> sure, if the frame pointer was set, than it is the current CFA >>>>>>> register. >>>>>>> If we request to adjust the current CFA register offset indicating it >>>>>>> being SP (while it's actually FP) that is indeed not correct and the >>>>>>> incoherence we will be detected by an assertion in the dwarf emission >>>>>>> machinery. >>>>>> Thanks, the patch is ok >>>>>> Kyrill >>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Andrea >>>>> >>>>> Hmm, wait. Why would a multi-reg pop be updating the stack pointer? >>>> >>>> Hi Richard, >>>> >>>> not sure I understand, isn't any pop updating SP by definition? >>> >>> >>> Back on this, >>> >>> compiling: >>> >>> ======= >>> int i; >>> >>> void foo (int); >>> >>> int bar() >>> { >>> foo (i); >>> return 0; >>> } >>> ======= >>> >>> With -march=armv8.1-m.main+fp -mbranch-protection=pac-ret+leaf >>> -mthumb -O0 -g >>> >>> Produces the following asm for bar. >>> >>> bar: >>> @ args = 0, pretend = 0, frame = 0 >>> @ frame_needed = 1, uses_anonymous_args = 0 >>> pac ip, lr, sp >>> push {r3, r7, ip, lr} >>> add r7, sp, #0 >>> ldr r3, .L3 >>> ldr r3, [r3] >>> mov r0, r3 >>> bl foo >>> movs r3, #0 >>> mov r0, r3 >>> pop {r3, r7, ip, lr} >>> aut ip, lr, sp >>> bx lr >>> >>> The offending instruction causing the ICE (without this patch) when >>> emitting dwarf is "pop {r3, r7, ip, lr}". >>> >>> The current CFA reg when emitting the multipop is R7 (the frame >>> pointer). If is not the multipop that has the duty to restore SP as >>> current CFA here which other instruction should do it? >>> >> Digging a bit deeper, I'm now even more confused. >> arm_expand_epilogue contains (parphrasing the code): >> if frame_pointer_needed >> { >> if arm >> {} >> else >> { >> if adjust >> r7 += adjust >> mov sp, r7 // Reset CFA to SP >> } >> } >> so there should always be a move of r7 into SP, even if this is >> strictly redundant. I don't understand why this doesn't happen for >> your testcase. Can you dig a bit deeper? I wonder if we've >> (probably incorrectly) assumed that this function doesn't need an >> epilogue but can use a simple return? I don't think we should do >> that when authentication is needed: a simple return should really be >> one instruction. >> > > So I strongly suspect the real problem here is that use_return_insn () > in arm.cc needs to be updated to return false when using pointer > authentication. The specification for this function says that a > return can be done in one instruction; and clearly when we need > authentication more than one is needed. > > R. So yes I agree with your analysis. I'm respinning 10/15 to include your suggestion and I believe we can just drop this patch. Thanks Andrea
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc index ceec14f84b6..a5cf4225aa2 100644 --- a/gcc/config/arm/arm.cc +++ b/gcc/config/arm/arm.cc @@ -22303,8 +22303,18 @@ arm_emit_multi_reg_pop (unsigned long saved_regs_mask) REG_NOTES (par) = dwarf; if (!return_in_pc) - arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs, - stack_pointer_rtx, stack_pointer_rtx); + { + /* If the frame pointer was set define again the stack pointer + as CFA reg. */ + if (frame_pointer_needed) + { + RTX_FRAME_RELATED_P (par) = 1; + add_reg_note (par, REG_CFA_DEF_CFA, stack_pointer_rtx); + } + else + arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs, + stack_pointer_rtx, stack_pointer_rtx); + } } /* Generate and emit an insn pattern that we will recognize as a pop_multi