Richard Earnshaw <richard.earns...@foss.arm.com> writes: > On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: >> Richard Earnshaw <richard.earns...@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.cora...@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
