EH_RETURN_STACKADJ_RTX / EH_RETURN_DATA_REGNO vs. EH_RETURN_HANDLER_RTX / eh_return

[Joern Rennecke <joern dot rennecke at superh dot com>]

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.

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.

Yet the documentation of EH_RETURN_HANDLER_RTX says:
@item EH_RETURN_HANDLER_RTX
A C expression whose value is RTL representing a location in which
to store the address of an exception handler to which we should
return.  It will not be assigned on code paths that return normally.

Well, if __builtin_eh_return is called in the current function,
there are no such code paths: either we got an exception return,
or undefined behaviour.

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.

So why do we bother to poke the return address on the stack in
various ports?  If there is another call-clobbered register
available, we can just use that, and use it for the return address
in the epilogue.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658