https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
Bug ID: 84521
Summary: [8 Regression] aarch64: Frame-pointer corruption with
setjmp/longjmp and -fomit-frame-pointer
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
CC: jgreenhalgh at gcc dot gnu.org, marcus.shawcroft at arm dot
com,
rearnsha at gcc dot gnu.org, wilco at gcc dot gnu.org
Target Milestone: ---
Host: aarch64-unknown-linux-gnu
Target: aarch64-unknown-linux-gnu
Build: aarch64-unknown-linux-gnu
The downstream bug report here:
https://bugzilla.redhat.com/show_bug.cgi?id=1545239
describes a problem seen on aarch64 with gcc 8 that breaks the build of Ruby at
-O1 and above.
Bisection shows that the problem started with r254815, which made
-fomit-frame-pointer the default.
Jakub reported:
> It is actually much older, I get the same crash if vm.c is compiled with
> -mlittle-endian -mabi=lp64 -g -grecord-gcc-switches -O1 -Wall
> -Werror=format-security
> -fexceptions -fPIC -fstack-protector -fno-strict-overflow
> -fexcess-precision=standard -fomit-frame-pointer
> with r204770, so already GCC 4.9 behaves that way too.
> Note ruby uses -fno-omit-frame-pointer already, but only on mingw32.
The issue is that the code generated for __builtin_longjmp reads a value for
x29 (the frame pointer) from the jmp_buf, but the code generated for
__builtin_setjmp doesn't actually write x29 to the jmp_buf, leading to
corruption of x29 when a longjmp occurs.
This corruption seems to be short-lived when -fno-omit-frame-pointer (the old
default), as every function restores x29 from the stack on exit.
With the new default of -fomit-frame-pointer the corruption can survive long
enough to cause crashes.
There's a lot more analysis at the downstream bug report in the URL above.
I'm about to attach a reproducer.
I'm marking this as "[8 Regression]" since although this is appears to be a
long-standing bug, the change of default in r254815 exposes it by default.
