From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4C3213858439 for ; Mon, 25 Jul 2022 10:41:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C3213858439 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7B6E12B; Mon, 25 Jul 2022 03:41:37 -0700 (PDT) Received: from [10.2.78.52] (unknown [10.2.78.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 33E203F73D; Mon, 25 Jul 2022 03:41:36 -0700 (PDT) Message-ID: <86a735ce-f41c-967c-45cd-8e3965d283bf@foss.arm.com> Date: Mon, 25 Jul 2022 11:41:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 9/12 V2] arm: Make libgcc bti compatible Content-Language: en-GB To: Andrea Corallo Cc: Richard Earnshaw , nd , Andrea Corallo via Gcc-patches References: <6c251f00-6b73-110c-d2b3-5e115ed6912b@foss.arm.com> From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3490.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2022 10:41:38 -0000 On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote: > Richard Earnshaw writes: > >> On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: >>> Richard Earnshaw 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 >>>>> * 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