On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote:
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).
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
