[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[will at kernel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424

Will Deacon  changed:

   What|Removed |Added

 CC||will at kernel dot org

--- Comment #1 from Will Deacon  ---
I just ran into this with GCC 9.2 and reproduced on trunk. The combination of
-fpatchable-function-entry with -mbranch-protection={standard,bti} is likely to
be used for building the Linux kernel when in-kernel BTI is used in conjunction
with dynamic function tracing. I think this will be a common configuration, so
although forcing the options to be mutually exclusive is definitely better than
broken codegen, ultimately we're going to need a way to combine them.

I suspect that placing the PACIASP before the NOPs is going to be problematic
unless it's done for all functions (including leaf functions), otherwise
hooking the NOPs at runtime is difficult because you can't tell whether or not
x30 is signed. You may end up needing to use BTI for the target instead.

The Clang folks are starting to look at -fpatchable-function-entry for AArch64
and will need to follow whatever you end up doing here.

[Bug inline-asm/91111] [7/8 Regression] arm64 Linux kernel panics at boot due to unexpected register assignment in inline asm

[will at kernel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

--- Comment #2 from Will Deacon  ---
Sorry to nag, but there's a discussion on LKML [1] about reducing the use of
the __always_inline attribute in favour of deferring inlining decisions to the
compiler. However, without an understanding of the root cause of this issue,
I'm very nervous about such a proposal for AArch64 targets.

Did you manage to get to the bottom of this issue, so that we can figure out
whether it could occur more widely or not (e.g. for 32-bit ARM or for register
variables used elsewhere)?

[1]
https://lore.kernel.org/lkml/20190830034304.24259-1-yamada.masah...@socionext.com/