[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Bill Schmidt  ---
So, not a gcc bug.  Closing.

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[rcardoso at linux dot vnet.ibm.com]

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

--- Comment #4 from Rogerio Alves  ---
(In reply to Tulio Magno Quites Machado Filho from comment #2)

> This is loading 0 because of glibc bug #21895, where the TOC pointer is not
> restored in the stack frame for static programs.
> That's why the the segfault happens.

Yes it's happening because TOC pointer is not being restored. In fact I already
sent a patch to libc that fix this. But, I was not sure about this behavior on
alloca.

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
The link in Tulio's comment came out wrong.  The correct link to the glibc
bugzilla is:  https://sourceware.org/bugzilla/show_bug.cgi?id=21895

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[tuliom at linux dot ibm.com]

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

--- Comment #2 from Tulio Magno Quites Machado Filho  ---
I don't think this is a bug.  At least not an alloca() bug.
Let me explain:

(In reply to Rogerio Alves from comment #0)
> 0x3fffb7fb0908 :  stdur1,-128(r1)

The stack frame starts with 128B

> B+>0x3fffb7fb092c <+56>:  stdur9,-272(r1)

Increases to 128+272 = 400B.
Which I think is more than enough for this function.

> Notice, that stdu r9,-272(r1) move the stack pointer to alloca(te) the space
> on the stack. Now $r1 (stack pointer) is 0x3fffefd0 on my tests.

So, TOC, LR, CR and the backchain are stored in this new place.
There used to be a code copying these values to the new place, but as this
function never returns, the compiler is not copying the values to the new
place.

I don't think this optimization is wrong, though.
Copying the values to the new place wouldn't help anyway because the code
before alloca() still expects these values to be in their old place.

> After the 3th iteration he will execute the code above on address
> 0x30e0 which is the caller stack frame (previous sp) and will set
> the 32 bits after with zeros.

This is the old place of the backchain.  It's now reserved for alloca().
So, looks good to me.

> The caller stack frame is gone and when
> longjmp executes we get a Segmentation Fault at:
> 
> 0x3fffb7fb0954  ld  r2,24(r1)   

This is loading 0 because of glibc bug #21895, where the TOC pointer is not
restored in the stack frame for static programs.
That's why the the segfault happens.

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-23
 Ever confirmed|0   |1
  Known to fail||6.3.0, 9.0

--- Comment #1 from Bill Schmidt  ---
Fails on trunk also.