[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

["wilco at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #14 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> Even when you find another PR for __builtin_longjmp (clearly RA related),
> that doesn't mean that __builtin_{setjmp,longjmp} are totally broken and
> should not be fixed on aarch64.  As ruby (which for some cryptic reason has
> been using those for quite some time) shows, it was working properly for
> years in real-world cases, except on aarch64 with -fomit-frame-pointer. 
> AFAIK this issue is with __builtin_setjmp or what it is lowered into, not
> __builtin_longjmp, so isn't really related to PR64242.
> __builtin_setjmp/longjmp is described as saving/restoring fewer registers
> than setjmp/longjmp but with the help of the prologue/epilogue of the frame
> containing the __builtin_setjmp call.  So if the help on aarch64 needs to be
> frame pointer, let's add it, if it needs to be something else,
> cfun->has_nonlocal_labels can be checked elsewhere too.  Don't other
> non-local gotos suffer a similar problem?

The fact that Ruby happen to work without crashes doesn't imply that
__builtin_longjmp/setjmp are 100% correct. The existing implementation breaks
the AArch64 ABI since it uses the frame pointer as an argument register. Using
the framepointer this way (broken frame chain) is explicitly disallowed by the
ABI. On x86 it can corrupt its own framepointer, but that's possible on other
targets too if you're unlucky.