Re: EH_RETURN_STACKADJ_RTX / EH_RETURN_DATA_REGNO vs. EH_RETURN_HANDLER_RTX / eh_return

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Wed, 13 Nov 2002, Joern Rennecke wrote:

> As far as I can see, it is the job of the epilogue generator to
> generate a stack adjustment to add EH_RETURN_STACKADJ_RTX, and
> this is then conditionalized on current_function_calls_eh_return.

Yup, either the usual epilogue or eh_return if that exists.

> This means that the epilogue is unsuitable for a code path where
> __builtin_eh_return is not called, as EH_RETURN_STACKADJ_RTX would
> be uninitalized, and thus a random value would be added to the
> stack pointer.

It is my understanding that EH_RETURN_STACKADJ_RTX is set to
const0_rtx then.  [checking again... yep, see expand_eh_return.]

A target does not *need* the eh_return pattern if the usual
epilogue code looks at current_function_calls_eh_return and if
that's nonzero:

- adds EH_RETURN_STACKADJ_RTX to the stack-pointer.
- restores all EH_RETURN_DATA_REGNO, even if they're
  normally clobbered.

The prologue must must likewise not forget to save (it suffices
to just allocate stack for and dwarf2-mark that space) all
EH_RETURN_DATA_REGNO when current_function_calls_eh_return is
nonzero.

> Moreover, because EH_RETURN_STACKADJ_RTX and EH_RETURN_DATA_REGNO
> typically use call-clobbered registers, there must be no function
> call between __builtin_eh_return and the epilogue.

That's handled by a jump emitted by expand_builtin_eh_return to
a label where code is emitted by expand_eh_return.

Or maybe I don't understand the question.  Note the EH tutorial
posted some months ago has some flaws; for one (IIRC) it
presents eh_return as a required pattern for DWARF2 EH and
doesn't mention the dwarf2out_* machinery.  Don't trust it;
consult the code and existing ports.  (And don't trust me. ;-)
Sorry for not getting around to post remarks on it.

brgds, H-P