https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687
Bug ID: 77687
Summary: frame access after release without redzone on powerpc
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hainque at gcc dot gnu.org
CC: segher at kernel dot crashing.org
Target Milestone: ---
Target: powerpc-elf, powerpc-eabispe
Created attachment 39672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39672&action=edit
testcase
As discussed with Segher at the GNU cauldron this summer,
filing a PR for the problem described and discussed from
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01337.html
The problem is still visible on mainline with a cross compiler
configured for powerpc-elf, on this artificial case
forcing the right combination of internal circumstances:
/* t.c */
void g(int, char *);
const char * dum = "hello";
void f(int x)
{
char big[200000];
start:
g(x, big);
g(x, big);
register void *p asm("r11") = &&start;
asm("" : : "r"(p));
asm("" : : :"r28");
asm("" : : :"r29");
asm("" : : :"r30");
}
./cc1 -O2 t.c -o - -mregnames
lwz %r11,0(%r1) # retrieve frame pointer
...
mr %r1,%r11 # release frame
lwz %r29,-12(%r11) # read from frame
mtlr %r0
lwz %r30,-8(%r11) # ...
lwz %r31,-4(%r11) # ...
blr
I'll attach the patch we have been using locally as
a stop-gap measure.
At some point in the thread, from
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00764.html
Segher suggested:
<< I think the best thing to do is add the clobber-of-mem-scratch to the
final stack deallocate (as a parallel). I don't see anything else that
will work reliably. >>
I have the start of a patch for this as well (based on gcc-6).
Still missing the definition of the proper insn pattern to recognize
the parallel.
Olivier
