[PATCH][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

[Szabolcs Nagy]

On 21/01/2020 17:51, Fāng-ruì Sòng via gcc-patches wrote:
> The Clang inconvenience is in the other way...
> 
> (My previous Clang patch series do not implement M>0.
>  https://reviews.llvm.org/D73070 will add support for M>0.)
> 
> AsmPrinter (assembly printer/object file emitter) does the following:
> 
> 1. Emit data before the function entry
> 2. Emit the function entry label and the label for __patchable_function_entries
> 3. Emit the function body
> 
> The function body has already been constructed before AsmPrinter. Among
> late-stage machine code passes, -fpatchable-function-entry=,
> -mbranch-protection= (AArch64 BTI) and -fcf-protection= (Intel Indirect
> Branch Tracking) are implemented as passes which can prepend
> instructions to the function body.
> 
> To do (b), step 2 needs to be split. The code generator should somehow
> know the label for __patchable_function_entries is after bti
> c/endbr32/endbr64.

or you can do a hack in 'emit function entry label'
(assuming there is a hook for that) so instead of
printing 'foo:' you print 'foo: bti c'

> Before forming a decision, I think we should also consider whether M>0
> will be possible in the future. Taking M>0 into consideration, is (a) or
> (b) more consistent?
> 
> Linux/arch/arm64/Kconfig currently uses -fpatchable-function-entry=2,0
> but M>0 could be useful for other architectures (arch/parisc already uses 1,1).

i think then checking for the bti is unavoidable:
some functions may miss the bti c, so simple logic
to jump over the bti at fixed offset is not enough.

but this complication is only needed if the function
label is in the middle of the patch area.