https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107248
Bug ID: 107248
Summary: Sparc V8 Invalid Stack Pointer Code
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dennis.borde at ohb dot de
Target Milestone: ---
Created attachment 53700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53700&action=edit
source code to trigger the bug
Environment: GCC V7.1.0, Sparc V8, RTEMS V4.8.0
When compiling with optimization level -O2 (including -fschedule-insns2) the
compiler generates code like this:
(1) add %sp, 0x50, %g1
(2) add %sp, 0x50, %sp
(3) add %g1, %o0, %o0
(4) ld [ %o0 + -8 ], %o0
In line (2) the stack pointer is moved by 80 bytes forward, which means memory
is "freed".
In line (4) it accesses the "freed" stack memory.
When an interrupt occurs in between line (2) and (4) it will overwrite the
stack data and "corrupt" it for the reading in line (4).
E.g.: As part of the RTEMS _ISR_Handler() the interrupt stack frame is stored
(see label symbol save_isf). For more information see RTEMS source code.
However, this is just one example to show the order of instructions above is
not safe. It is not important for the bug itself.
Work-around: Compile with -fno-schedule-insns2
With the work-around the generated code looks like this:
(1) add %sp, 0x50, %g1
(2) add %g1, %o0, %o0
(3) ld [ %o0 + -8 ], %o0
(4) add %sp, 0x50, %sp
Here the stack memory is "freed" (4) after the access (3).
It seems to be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
