From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Richard.Earnshaw@foss.arm.com>
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by sourceware.org (Postfix) with ESMTP id 247C83858D28
 for <gcc-patches@gcc.gnu.org>; Thu, 21 Jul 2022 11:41:10 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 247C83858D28
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 477471042;
 Thu, 21 Jul 2022 04:41:10 -0700 (PDT)
Received: from [10.57.10.55] (unknown [10.57.10.55])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 59C0A3F70D;
 Thu, 21 Jul 2022 04:41:08 -0700 (PDT)
Message-ID: <a8382060-516e-046e-4183-d38b120e6c22@foss.arm.com>
Date: Thu, 21 Jul 2022 12:41:06 +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 <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>
References: <gkrmtg5wqik.fsf@arm.com> <gkrk0b9v8ql.fsf@arm.com>
 <6c251f00-6b73-110c-d2b3-5e115ed6912b@foss.arm.com>
 <gkrmtd2964g.fsf_-_@arm.com>
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
In-Reply-To: <gkrmtd2964g.fsf_-_@arm.com>
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 <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>
X-List-Received-Date: Thu, 21 Jul 2022 11:41:11 -0000

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.