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? And then is RA at regs[CFI_BP].offset + 8? -- Josh