Richard Sandiford wrote:

> In other words, the reason seemed to be that the _Unwind_SetGRPtr in:
> 
> #ifdef EH_RETURN_STACKADJ_RTX
>   /* Special handling here: Many machines do not use a frame pointer,
>      and track the CFA only through offsets from the stack pointer from
>      one frame to the next.  In this case, the stack pointer is never
>      stored, so it has no saved address in the context.  What we do
>      have is the CFA from the previous stack frame.
> 
>      In very special situations (such as unwind info for signal return),
>      there may be location expressions that use the stack pointer as well.
> 
>      Do this conditionally for one frame.  This allows the unwind info
>      for one frame to save a copy of the stack pointer from the previous
>      frame, and be able to use much easier CFA mechanisms to do it.
>      Always zap the saved stack pointer value for the next frame; carrying
>      the value over from one frame to another doesn't make sense.  */
> 
>   _Unwind_SpTmp tmp_sp;
> 
>   if (!_Unwind_GetGRPtr (&orig_context, __builtin_dwarf_sp_column ()))
>     _Unwind_SetSpColumn (&orig_context, context->cfa, &tmp_sp);
>   _Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
> #endif
> 
> was conditional on EH_RETURN_STACKADJ_RTX being defined.  It looked at
> first glance like things would work if that call was moved outside,
> so that we never inherit save slots for the stack pointer.  Does that
> make sense?  I can give it a go tomorrow if so.

I haven't looked into this in detail right now, but I recall that I had
to specifically add that #ifdef a long time ago since unwinding wouldn't
work correctly on s390 otherwise:
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00904.html

And the background of the bug here:
http://gcc.gnu.org/ml/gcc/2003-05/msg00536.html

Actually, now I think the problem originally described there is still
valid: on s390 the CFA is *not* equal to the value at function entry,
but biased by 96/160 bytes.  So setting the SP to the CFA is wrong ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Reply via email to