Re: rs6000 stack_tie mishap again

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Apr 15, 2016 at 07:05:25PM +0200, Olivier Hainque wrote:
> > But don't you run the risk that the stack could be deallocated before the restores are done?  This came up on the PA port a long time ago. IIRC the situations was something like this:
> > 
> > We had a frame pointer and all the restores were being done via the frame pointer.  So the scheduler moved the stack pointer adjustment up past the register restores.  At which point the restores were reading from unallocated stack space.
> > 
> > 99.99% of the time it didn't cause a problem.  But if we got an interrupt in that brief window, boom, the interrupt handler could allocate a frame on the current stack, store some data in there which clobbered the saved register state.
> 
> Yes, that's exactly the kind of problem we're fighting and, indeed,
> the memory barrier alone isn't enough.
> 
> Here, the idea is to add a memory barrier to the set of things that the rs6000
> back-end already does, which tries to be better than a complete scheduling
> barrier (see rs6000_emit_stack_tie), but turns out to still fail in some corner
> cases due to alias analysis intricacies (original problem description at
> the very beginning of this now long thread: 
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01337.html)

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.


Segher