This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] First attempt@unwind epilogue support for s390{,x}

Richard Henderson wrote:
> Ulrich Weigand wrote:
> >>> +      REG_NOTES (insn) = cfa_restores;
> >>> +      add_reg_note (insn, REG_CFA_DEF_CFA,
> >>> +		    plus_constant (stack_pointer_rtx, STACK_POINTER_OFFSET));
> >> Given the above, I might think that the only safe CFA definition
> >> for the return insn is CFA = SP + 0.
> > 
> > Well, as mentioned above, it needs to be CFG = SP + STACK_POINTER_OFFSET.
> The unwind state exactly at the return instruction would
> appear to be a special case.
> Consider how the unwinder will view the state of the
> program at that location:  The return address is loaded
> in the appropriate return register, all saved registers
> are restored, including the stack pointer.  However, we
> still need to unwind to the caller.

This should be exactly the same state as during a leaf function
that does not allocate any stack, so I'm not sure why this needs
to be treated in a special way ...

> Since there's no copy of the stack pointer value remaining
> on the stack (is this true, or is there a red-zone?), the
> saved-stack-value-overrides-copy-cfa-to-sp logic does not
> fire, which means that if we set CFA=SP+OFFSET, then we'll
> assign SP = SP+OFFSET during the unwinding.  Which will if
> I am not greatly mistaken, give incorrect results for the
> rest of the unwinding.
> Or is there some hack in the unwinder that I can't find?

This special SP=CFA logic (_Unwind_SetSpColumn etc.) is not
active at all on s390 in uw_update_context_1 because the
EH_RETURN_STACKADJ_RTX macro is not defined.

The special logic in uw_install_context_1 is compiled in,
but should never trigger: if there is any frame on the
chain that doesn't save SP (leaf function, or regular
function just on the return), this can only happen if
there's a signal stack frame just below.  That signal
frame will contain a slot for the SP in the leaf function,
which will have been copied up and used as the slot for SP
in the leaf function's caller as well (as the leaf function
will have marked SP as having the same value as its caller).

Am I overlooking anything here?


  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]