Hi Jakub,
>> We could simpify __builtin_eh_return and implement it as a libgcc
>> function or automatically generated thunk. Basically all you need is
>> tailcall a 2-instruction helper which adjusts the stack and then jumps
>> to the given function pointer. This way you don't need the complex
>> special cases and optimization disables for eh_return functions.
>
> That is a serious misunderstanding of what __builtin_eh_return does.
And this is exactly the issue - it's undocumented/untested. There isn't a
well-defined interface that makes it clear which part of the feature is
implemented by the midend and which part must be done by each backend.
> For the most part, __builtin_eh_return works by forcing all call clobbered
> registers to stack, having that described in the unwind info and having the
> unwinding code modify that saved info when needed.
Sure, and that's target independent.
> The adjustment of the
> stack is done only on approx. half of the targets where the destination
> stack pointer should be derived from CFA instead of being restored with the
> rest of the call saved registers. You can't do this in assembly, it needs
> to be done in the same function that saves the state etc.
No, it can be done by a simple 2-instruction thunk. Targets which save the stack
pointer don't require it since they restore SP already.
You could also enter the unwinder via a small assembler veneer which saves the
callee-save registers and stack pointer (a bit like setjmp), and the unwinder
will
work just fine.
Once you decide what the specification is, the implementation becomes really
trivial. But without it, every target is just guessing what it should implement.
Wilco
