On 10/12/20 4:35 PM, Josh Poimboeuf wrote:
On Mon, Oct 12, 2020 at 11:21:49AM +0100, Julien Thierry wrote:
On 9/29/20 8:18 PM, Josh Poimboeuf wrote:
"Stack frame" has more than one meaning now, I suppose. i.e. it could
also include the callee-saved registers and any other stack space
allocated by the function.
Would "call frame" be clearer?
CALL_FRAME_BP_OFFSET
CALL_FRAME_RA_OFFSET
?
I would've thought that the call-frame could include the stackframe + other
callee saved regs.
Hm, probably so.
Whereas stackframe tends to used for the caller's frame pointer +
return address (i.e. what allows unwinding). Unless I'm getting lost
with things.
I've always seen "stack frame" used to indicate the function's entire
stack.
And if call frame is associated with the region starting from the stack
pointer at the parent call point (since this is what CFA is), then it
shouldn't be associated with the framepointer + return address structure
since this could be anywhere on the call frame (not at a fixed offset) as
long as the new frame pointer points to the structure.
I suppose "call frame" and "stack frame" probably mean the same thing,
in which case neither is appropriate here...
In fact, maybe we could forget the concept of a frame (or even a struct)
here.
If cfa.base is CFI_BP, then is regs[CFI_BP].offset always the same as
-cfa.offset? i.e. could the BP checks could it just be a simple
regs[CFI_BP].offset == -cfa.offset
check?
I guess that makes sense. If the above was no true it would mean that BP
is not pointing to the unwind information.
And then is RA at regs[CFI_BP].offset + 8?
In the case of aarch64, the saved frame pointer and return address
appear in the same order as on x86_64. So that would work. If that can
make things simpler for now I can go with that.
Thanks for the suggestion.
--
Julien Thierry
