Message ID | gkrmtd2964g.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:adf:e252:0:0:0:0:0 with SMTP id bl18csp1348385wrb; Thu, 21 Jul 2022 02:18:57 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tekHV2UxcKnC69hIaVyaui4cSDycF62N3JapBbqtuLiC20KyYt3O82x+jUXc0WF7IsA7AT X-Received: by 2002:a17:907:b590:b0:72b:91f3:d4ef with SMTP id qx16-20020a170907b59000b0072b91f3d4efmr40342394ejc.29.1658395137081; Thu, 21 Jul 2022 02:18:57 -0700 (PDT) Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id q20-20020aa7d454000000b0043a40d536d1si1571818edr.513.2022.07.21.02.18.56 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 02:18:57 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=jl79Sile; arc=fail (signature failed); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 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 D4365385AE71 for <ouuuleilei@gmail.com>; Thu, 21 Jul 2022 09:18:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4365385AE71 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1658395133; bh=YfpXL/kl3lvamZxojDbT/+OQfemcKFsKhNfujqs8peY=; 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=jl79Silecm5eTceRX33JQPvIVqaScMFSwUGl8U0V9EDDX8413P0nNpmYYUNjHOMe3 Vy0o6+RK6MbXXLrIK82OepcJ0RLq59YzFc2tDpbMPDeuLai+lcTCkQx+TUh93iRrmv 3h/rJewEllb12XLc03EERu+TR0GHBb33ry+Mfj9M= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2082.outbound.protection.outlook.com [40.107.22.82]) by sourceware.org (Postfix) with ESMTPS id 4E3ED3856DEC for <gcc-patches@gcc.gnu.org>; Thu, 21 Jul 2022 09:18:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4E3ED3856DEC ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=mRvsj+O1syAjNHOKuQBxVLv9FNSZ4bLLhB/PtQJO90a4LldyoWoh2XyQ5scXk+yOOpibwIM7qKGmFo4i1Q0oQHUWFvFefh7Nz/Fk8/IJr18wi0irVe8Mbepns31jAu8PkyzhR/rzCO6PVd12J9Dp2gS1KT7pN3+kf8MRuEpdQoD0pUwQrmLkBKvd4Aed4mRpfRZiQXm/tqfWcqOYCkHFIRMxuS2Ve/7p0NguUPpo8RFxLJB4ixp0N73gcqmIZ25zdl6qB4l1im76Qy1WWuJrmEJKL5DbIqAKxOyHk6HocNpLkXlhQW2FjtWUrAbh0jI1rqNyPy2t9W0TRmhOUajP+A== 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=YfpXL/kl3lvamZxojDbT/+OQfemcKFsKhNfujqs8peY=; b=CpMrGlOUtyJJmIoFPLeFMEUFi42UTYFKZvycbbx/hJ6SZnSV+VHVfIYYYbVpNjPVBZrnAkS39nCBKjLJXiD/vsDHCg9UrLtaJRUkxHsKbYV+TcFchIszBHzbvoDXb9N4VUnRB1Liud8Deq2wiB5xC2e1aIYvpLQBnJ08VtMS7tN/Ucx3cYxswRq4SwiMObTbFenGHl91S7oRgs2xX209nhsZDQuxpecUuABLt8RBlp/8qzdyOqTeNy8pkk6gE74DIfl6rySlbLmsZ+J9XgGrCIC/ldr5G0AkSZ/Cn1gyNKoz0Uu2vHHk4HlFsxNqOclO3Qk1NkSsTnZvoQW89VFvgQ== 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 AM6P191CA0055.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:7f::32) by VI1PR08MB3840.eurprd08.prod.outlook.com (2603:10a6:803:b5::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.14; Thu, 21 Jul 2022 09:18:03 +0000 Received: from AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:7f:cafe::2e) by AM6P191CA0055.outlook.office365.com (2603:10a6:209:7f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19 via Frontend Transport; Thu, 21 Jul 2022 09:18:03 +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 AM5EUR03FT050.mail.protection.outlook.com (10.152.17.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.17 via Frontend Transport; Thu, 21 Jul 2022 09:18:02 +0000 Received: ("Tessian outbound fa99bf31ee7d:v123"); Thu, 21 Jul 2022 09:18:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f9ced8b74eb7d6ce X-CR-MTA-TID: 64aa7808 Received: from 37445706f141.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1F4D666F-DCDE-484B-8399-ADFDA8111123.1; Thu, 21 Jul 2022 09:17:56 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 37445706f141.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 21 Jul 2022 09:17:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+zzVSG5ljzd6tSuLMzE4eVSFi/SS06IWa3N0i3476LcM7yRZ3RISSVJmEf4Ca/hjyushfOZwYO2U4OhSibLKRJzt7FWD0W3216spFOwfpUc0K6rlZtNtWf17WQW23RsjDWASSMImRfsyNk4vS4l15KzE5b7kAoyp9lULvpJ1tWJ3lO0E5ob3h8QiUbop/9zBXkSwa0AV0Hm4wewAiFj2amC54Uc996HHmhz6Q64twzFUT3MZlaSt6aoFHFwxSEhRFiRZeJA0DpdH6okhJN2TnRFyRu+QDFsyhz3j/Ehx41rAmFWOFJ+uZYzXwSR6XMkR/sYlNPwlIZsdYXWhe9t7A== 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=YfpXL/kl3lvamZxojDbT/+OQfemcKFsKhNfujqs8peY=; b=gZ/rIb8yPFcZNa8rckVZ6RNOIMYoPvhV4a6aGS7K+WuCS9D3J1V46HF6sdN/fflMOFFkApIQtHBNFGyxB9bvVG6mvKoKzc2sWmJBJE9/TuosEHbVeL7j+qoRskFzwlh0IgweTQbewf3x+gTztpecTIXXq4amPQGy1lb3IxMW2EUUeW59He3Y5L4mFpfruORee4HvVKw2g2NhoBmcx3vFzPT9aVXCKeFGeiumxGlyb9W8UB3drTW4eAPARk5gJ1gWhIN1RgAy+E2yDm6NoEsm05PAtwnpT87/HTuq2xuNB8nQPghKKVRX2TGf/9wdMHdenq6h4t3jRD55kqqs1ZpLVw== 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 AM6P195CA0064.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::41) by AM5PR0802MB2515.eurprd08.prod.outlook.com (2603:10a6:203:9f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.18; Thu, 21 Jul 2022 09:17:54 +0000 Received: from VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::34) by AM6P195CA0064.outlook.office365.com (2603:10a6:209:87::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19 via Frontend Transport; Thu, 21 Jul 2022 09:17:54 +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 VE1EUR03FT043.mail.protection.outlook.com (10.152.19.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5438.12 via Frontend Transport; Thu, 21 Jul 2022 09:17:53 +0000 Received: from AZ-NEU-EX01.Emea.Arm.com (10.251.26.4) by AZ-NEU-EX04.Arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.9; Thu, 21 Jul 2022 09:17:52 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX01.Emea.Arm.com (10.251.26.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.9; Thu, 21 Jul 2022 09:17:51 +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; Thu, 21 Jul 2022 09:17:51 +0000 To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com> Subject: [PATCH 9/12 V2] arm: Make libgcc bti compatible References: <gkrmtg5wqik.fsf@arm.com> <gkrk0b9v8ql.fsf@arm.com> <6c251f00-6b73-110c-d2b3-5e115ed6912b@foss.arm.com> Date: Thu, 21 Jul 2022 11:17:51 +0200 In-Reply-To: <6c251f00-6b73-110c-d2b3-5e115ed6912b@foss.arm.com> (Richard Earnshaw's message of "Fri, 1 Jul 2022 16:03:49 +0100") Message-ID: <gkrmtd2964g.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: 05692e83-46f2-48d6-4823-08da6af9e9da X-MS-TrafficTypeDiagnostic: AM5PR0802MB2515:EE_|AM5EUR03FT050:EE_|VI1PR08MB3840: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: PE5RKy5iUPlQsY6BXYE5W6A1AdCO0hpvk/pXsChrKA+h0JR/SJ3jD2q6GN5tHUHV2KUDDykBTYD3kOqANwRfrAU6jnQc9cAXaztLc5cKNcOu/nnj2GS3sF4nyWzAx6knUpla6myNZSK2JgYm7tp8ZcL3yngUZOIPDo+tWqWCmwCAbcuyEN85yPrqk42TkvQGqP/qs9nLeWU66HjsVXKcrNdHVH6R/2h8ruaNgQku8/mPLLEhcAlqIovINZUyEU3RPNdui8nhZBYONr5j7SMUXC4rPtnZfYb/6qH/aRbFI5H7y4CBdJgaHT3q1ghZE3L+imzlQv9O23U5i820u8YnKsbTnzmv0MRH0B+JC2w0lthWJE1nNImpT+n9k9z7qwlSoXnQoqTT5Iv/bMlYo9Aqi0I13Xvg3p7/+GS/nLIg5PYRH69xOYa+NrhXcUWpXlilbFchvK3lhYTJvqO80CQlMDDeVv2owz2M2hrkR1FtI1lgonXlCuwzqxiGhU/+riAE/EqZz81WR1JSfqlQwPwqGFzHczbvUfnl47NXinet8fTfwchmZOo1CCt08L4Zmv0WVdZ+K08A48x79/YX1OBBetVYERWkyqLxB2kf+NIYJVAydfCAnjTW5hNNmJRSvLuVQO0giM277qHm7mBuspRCbiWAuWjzrXQ5TXZdJfzQ2tow4a3Ve9u90d7hpQ5harisbM4sUZPun0Uqu3ifyU3GEryymql5hYySXQ0AxtfDhv+levlJYKyhx5jcNOKrot2AKMJSpb/Mk/+bry8Zrob7efXrpV9uuiyfHVc6JhchXBi75dszgjOAv+Fg0shxZ1CAWbxyRLDIwfQ84pQZPh1JZQ== 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)(346002)(39860400002)(376002)(136003)(396003)(40470700004)(36840700001)(46966006)(2906002)(4326008)(36860700001)(33964004)(336012)(26005)(47076005)(70586007)(40480700001)(53546011)(86362001)(70206006)(426003)(82310400005)(40460700003)(8676002)(5660300002)(8936002)(36756003)(356005)(81166007)(83380400001)(82740400003)(316002)(6862004)(2616005)(44832011)(186003)(235185007)(54906003)(478600001)(41300700001)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2515 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 80cf3525-81b9-42f6-e83e-08da6af9e491 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ow1bCimVNPRmz/3KIO/5xjDfI2c30IYyKP9zV12rhnY+mFP+4zeFXaPTljX6d1CWQ1LTBtq+shQ6AzAc4JZIDs1x0Xnv8zWVGgCcPCQUnsHR1bega0h9F07cSmcKi7WyJPtigoPIsCcNo6zhyv0weENzHIiDlUMCh4UseBfM1XE8AWL0yDoqHe/WKrTwYNR9Hs4S1yTKR8Gmr2RbGfIqxCIZHgSkyT+wWIa1z7WwC+J8kTqxfnTJza5BtzSA5+ZqTzf2pvybWdrTM1mp/88d4TPUC/wIuRclB4PaQJx/et3rtXj3UBazD8JpxWNPRtRGE9lTehe4gt35sUwSpjilaofCmA3FnyA5KOHMt9unjsjbhK1c3wxd0spwO2EHBdDZoF6vLI0iDakF0FKAMlRM8qeu9FzNx+cd612Srxan/0PdFiTHvgqMLVHiinSAW9azUoLeOpjbOPMJlHqfcj4VTsaZg8aszS5L0KsD8h6WLbxxp6tkZGGYVnG8sydhOaX8kUu9LFiY7tCBRCoCqlsbXQ4qwiGMOYOKgXrigqQxDkiwtw8rOtkSKtcYDWlfE4QA66ncx3tt7tlm7VmFEzx1fA6rBKqw9KaCLU2PUEZHlNkUQVdQ2XKb4v/6fw5+u7s+4Yb2vrw3u7vexZU4bMRM72Xxe7Zba/BWwW26KJGnmohWkhdN84A2jgefArUHM/wylUii5nTUSiLUvrH9gu8ovXXdpruCLT6Tuqml/9ZhBhIWCDvCkwavmciRp7FXUxbmr+NWUWHj+OVrYX759lQHFMKAJZ64ZOn+iSaP2laPwYZGYZBFQIW/yW4XH9NtUUdT 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)(376002)(136003)(396003)(346002)(39860400002)(40470700004)(36840700001)(46966006)(40460700003)(478600001)(41300700001)(186003)(26005)(2906002)(86362001)(83380400001)(53546011)(6862004)(8936002)(36860700001)(426003)(336012)(33964004)(5660300002)(2616005)(235185007)(47076005)(316002)(82740400003)(36756003)(70206006)(81166007)(44832011)(4326008)(8676002)(70586007)(54906003)(82310400005)(40480700001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2022 09:18:02.8519 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 05692e83-46f2-48d6-4823-08da6af9e9da 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: AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3840 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, 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>, Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> 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-LABELS: =?utf-8?b?IlxcSW1wb3J0YW50Ig==?= X-GMAIL-THRID: =?utf-8?q?1738953339396502644?= X-GMAIL-MSGID: =?utf-8?q?1738953339396502644?= |
Series | None | |
Commit Message
Li, Pan2 via Gcc-patches
July 21, 2022, 9:17 a.m. UTC
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: >> This change add bti instructions at the beginning of arm specific >> libgcc hand written assembly routines. >> 2022-03-31 Andrea Corallo <andrea.corallo@arm.com> >> * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction >> if >> necessary. >> * libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START): >> Likewise. >> > > +#if defined(__ARM_FEATURE_BTI) > > Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT? That way we > only get BTI instructions in multilib variants that have asked for > BTI. > > R. Hi Richard, good point, yes I think so. Please find attached the updated patch. BR Andrea From 6975c9ddbc8a4b790a765589c6fd07fea92173e5 Mon Sep 17 00:00:00 2001 From: Andrea Corallo <andrea.corallo@arm.com> Date: Tue, 8 Feb 2022 10:58:31 +0100 Subject: [PATCH] [PATCH 9/12] arm: Make libgcc bti compatible This change add bti instructions at the beginning of arm specific libgcc hand written assembly routines. 2022-03-31 Andrea Corallo <andrea.corallo@arm.com> * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction if necessary. * libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START): Likewise. --- libgcc/config/arm/crti.S | 4 +++- libgcc/config/arm/lib1funcs.S | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletion(-)
Comments
On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: > Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > >> On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: >>> This change add bti instructions at the beginning of arm specific >>> libgcc hand written assembly routines. >>> 2022-03-31 Andrea Corallo <andrea.corallo@arm.com> >>> * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction >>> if >>> necessary. >>> * libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START): >>> Likewise. >>> >> >> +#if defined(__ARM_FEATURE_BTI) >> >> Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT? That way we >> only get BTI instructions in multilib variants that have asked for >> BTI. >> >> R. > > Hi Richard, > > good point, yes I think so. > > Please find attached the updated patch. > > BR > > Andrea > I've been pondering this patch. The way it is implemented would put a BTI instruction at the start of every assembler routine in libgcc. But the vast majority of functions in libgcc cannot have their address taken, so a BTI isn't needed (BTI is only needed when an indirect jump could be used). So I wonder if we really need to do this so aggressively? Perhaps a better approach would be to define a macro (eg MAYBEBTI) which expands a BTI if the compilation requires it and nothing otherwise), and then manually insert that in any functions that really need this (if any). R.
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: >> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >> >>> On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: >>>> This change add bti instructions at the beginning of arm specific >>>> libgcc hand written assembly routines. >>>> 2022-03-31 Andrea Corallo <andrea.corallo@arm.com> >>>> * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction >>>> if >>>> necessary. >>>> * libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START): >>>> Likewise. >>>> >>> >>> +#if defined(__ARM_FEATURE_BTI) >>> >>> Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT? That way we >>> only get BTI instructions in multilib variants that have asked for >>> BTI. >>> >>> R. >> Hi Richard, >> good point, yes I think so. >> Please find attached the updated patch. >> BR >> Andrea >> > > I've been pondering this patch. The way it is implemented would put a > BTI instruction at the start of every assembler routine in libgcc. > But the vast majority of functions in libgcc cannot have their address > taken, so a BTI isn't needed (BTI is only needed when an indirect jump > could be used). So I wonder if we really need to do this so > aggressively? > > Perhaps a better approach would be to define a macro (eg MAYBEBTI) > which expands a BTI if the compilation requires it and nothing > otherwise), and then manually insert that in any functions that really > need this (if any). I guess the main downside of this approach would be the maintanace burden, we'll have to remember forever that every time an asm function is called by function pointer we have to add the bti landing pad manually, otherwise this will be broken when pacbti enabled. WDYT? If we want to go this way I'll start reworking the patch in this direction (tho this might not be trivial). BR Andrea
On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote: > Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > >> On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: >>> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >>> >>>> On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: >>>>> This change add bti instructions at the beginning of arm specific >>>>> libgcc hand written assembly routines. >>>>> 2022-03-31 Andrea Corallo <andrea.corallo@arm.com> >>>>> * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction >>>>> if >>>>> necessary. >>>>> * libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START): >>>>> Likewise. >>>>> >>>> >>>> +#if defined(__ARM_FEATURE_BTI) >>>> >>>> Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT? That way we >>>> only get BTI instructions in multilib variants that have asked for >>>> BTI. >>>> >>>> R. >>> Hi Richard, >>> good point, yes I think so. >>> Please find attached the updated patch. >>> BR >>> Andrea >>> >> >> I've been pondering this patch. The way it is implemented would put a >> BTI instruction at the start of every assembler routine in libgcc. >> But the vast majority of functions in libgcc cannot have their address >> taken, so a BTI isn't needed (BTI is only needed when an indirect jump >> could be used). So I wonder if we really need to do this so >> aggressively? >> >> Perhaps a better approach would be to define a macro (eg MAYBEBTI) >> which expands a BTI if the compilation requires it and nothing >> otherwise), and then manually insert that in any functions that really >> need this (if any). > > I guess the main downside of this approach would be the maintanace > burden, we'll have to remember forever that every time an asm function > is called by function pointer we have to add the bti landing pad > manually, otherwise this will be broken when pacbti enabled. WDYT? > > If we want to go this way I'll start reworking the patch in this > direction (tho this might not be trivial). > Yes, it's a trade-off. The lazy way, however, costs all users even if a function is never addressed (which I think is the case for practically all functions in libgcc). So I think in this case it's worth taking that extra development pain. R. > BR > > Andrea
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: > On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote: >> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >> >>> On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: >>>> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes: >>>> >>>>> On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: >>>>>> This change add bti instructions at the beginning of arm specific >>>>>> libgcc hand written assembly routines. >>>>>> 2022-03-31 Andrea Corallo <andrea.corallo@arm.com> >>>>>> * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction >>>>>> if >>>>>> necessary. >>>>>> * libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START): >>>>>> Likewise. >>>>>> >>>>> >>>>> +#if defined(__ARM_FEATURE_BTI) >>>>> >>>>> Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT? That way we >>>>> only get BTI instructions in multilib variants that have asked for >>>>> BTI. >>>>> >>>>> R. >>>> Hi Richard, >>>> good point, yes I think so. >>>> Please find attached the updated patch. >>>> BR >>>> Andrea >>>> >>> >>> I've been pondering this patch. The way it is implemented would put a >>> BTI instruction at the start of every assembler routine in libgcc. >>> But the vast majority of functions in libgcc cannot have their address >>> taken, so a BTI isn't needed (BTI is only needed when an indirect jump >>> could be used). So I wonder if we really need to do this so >>> aggressively? >>> >>> Perhaps a better approach would be to define a macro (eg MAYBEBTI) >>> which expands a BTI if the compilation requires it and nothing >>> otherwise), and then manually insert that in any functions that really >>> need this (if any). >> I guess the main downside of this approach would be the maintanace >> burden, we'll have to remember forever that every time an asm function >> is called by function pointer we have to add the bti landing pad >> manually, otherwise this will be broken when pacbti enabled. WDYT? >> If we want to go this way I'll start reworking the patch in this >> direction (tho this might not be trivial). >> > > Yes, it's a trade-off. The lazy way, however, costs all users even if > a function is never addressed (which I think is the case for > practically all functions in libgcc). > > So I think in this case it's worth taking that extra development pain. > > R. As a late follow-up to this. I believe there are no hand written asm functions in libgcc that are addressed, so this patch was dropped from the series in the following iteration. It is true that we could pac instrument them but ATM we don't. Andrea
diff --git a/libgcc/config/arm/crti.S b/libgcc/config/arm/crti.S index 0192972a7e6..4098353af1c 100644 --- a/libgcc/config/arm/crti.S +++ b/libgcc/config/arm/crti.S @@ -51,7 +51,9 @@ .macro FUNC_START #ifdef __thumb__ .thumb - +#if defined(__ARM_FEATURE_BTI_DEFAULT) + bti +#endif push {r3, r4, r5, r6, r7, lr} #else .arm diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S index 8c39c9f20a2..de98edcc300 100644 --- a/libgcc/config/arm/lib1funcs.S +++ b/libgcc/config/arm/lib1funcs.S @@ -345,6 +345,9 @@ LSYM(Ldiv0): TYPE (\name) .thumb_func SYM (\name): +#if defined(__ARM_FEATURE_BTI_DEFAULT) + bti +#endif .endm /* Function start macros. Variants for ARM and Thumb. */ @@ -372,6 +375,9 @@ SYM (\name): THUMB_FUNC THUMB_SYNTAX SYM (__\name): +#if defined(__ARM_FEATURE_BTI_DEFAULT) + bti +#endif .endm .macro ARM_SYM_START name