Re: GCC 3.3 Prelease broken on s390

[Ulrich Weigand <weigand at immd1 dot informatik dot uni-erlangen dot de>]

Richard Henderson wrote:

> Ah, now I get it.  This was the piece I couldn't understand.
> And if *this* is the case, it means that it doesn't matter
> where you place the CFA relative to the stack frame, just so
> long as the stack pointer itself is computed properly.

This is what I was thinking, yes.

> >         * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
> >         previous frame didn't save sp.  Clear sp for next frame.
> >         (uw_install_context_1): Honor saved sp from frame.
> 
> If this works, great.

Unfortunately, while it fixes most of the problems, it is not a
complete solution:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00418.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00419.html

The Java test case PR218 is still failing.  This is because
this test case throws an exception from a signal handler
through a *leaf* function that was interrupted by the
signal.

When unwinding through the leaf function, there is no CFA code
to restore the stack pointer, because the *correct* behaviour
would have been to reuse the stack pointer from the frame below
(the signal return stub frame) unchanged -- the leaf function
really did not allocate any stack space.

However, this now triggers again the new code that sets the
stack pointer to the cfa, incorrect on s390.

Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?

Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
on top of the current 3.3 implementation?

What about an alternate target macro that says that this target
handles SP by itself via FDE records, and doesn't need any
other SP fiddling?  This would then allow us to remove the 
unnecessary EH_RETURN_STACKADJ_RTX handling completely.
Maybe this behaviour could actually be triggered by the target
leaving EH_RETURN_STACKADJ_RTX undefined?

If no other solution works for 3.3, we could always fix it
ad-hoc with #ifdef __s390__ ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de