[PATCH,V1 00/14] Definition and support for SFrame unwind format

[Jan Beulich]

On 04.10.2022 07:16, Indu Bhagat wrote:
> re: return address was saved to some secondary stack. I need some more 
> understanding of the issue here. I was thinking an entity higher up, 
> like the unwinder, will have enough context to pick the appropriate 
> stack to which the stack offsets apply; because the decision as to when 
> to switch to a secondary stack (or not) must be a application specific 
> property ? If you have some resources to share here, it will be helpful. 
> Alternatively, if usage of secondary stack is specified at an ABI level, 
> can you please provide a reference so I can take a look ?

That's not the kind of "secondary stack" I was referring to. IA-64, for
example, had a 2nd stack for its Register Stack Engine (for kind of
implicit spilling of a subset of GPRs). The return address of a function
therefore can, in principle, land on either the normal or the RSE stack.

x86 has now gained a secondary stack as well, for CET-SS. If that's in
use, in principle I think it would be preferable to unwind using that
one (as there's far less stuff there which isn't a return address, and
in the common case going from one function's slot to the next means
merely incrementing/decrementing the pointer used to point into that
stack).

Jan