Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 3 Aug 2020 16:35:29 -0500 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v2 9/9] objtool: Abstract unwind hint reading |
| |
On Mon, Aug 03, 2020 at 01:13:14PM +0100, Julien Thierry wrote: > > > On 7/31/20 3:04 PM, Josh Poimboeuf wrote: > > On Fri, Jul 31, 2020 at 08:00:58AM +0100, Julien Thierry wrote: > > > > > + cfa->offset = hint->sp_offset; > > > > > + insn->cfi.hint_type = hint->type; > > > > > + insn->cfi.end = hint->end; > > > > > + > > > > > + insn->cfi.sp_only = hint->type == ORC_TYPE_REGS || hint->type == ORC_TYPE_REGS_IRET; > > > > > > > > What does "sp" mean here in sp_only? > > > > > > > > > > Stack pointer, like in CFI_SP. When objtool encounters one of these hints, > > > it starts to only track the stack frame with the stack pointer (no BP, no > > > drap register, no move to temporary registers). Just trying to make some > > > sense of this corner case. > > > > I think that's not quite right, because ORC_TYPE_CALL could also be > > "sp_only" in some cases, by that definition. > > > > But in that case the code will still track when/if the CFI becomes pointed > to by BP. > > > The call to update_cfi_state_regs() is really regs-specific, not > > sp-specific. > > > > I must admit I don't really understand what "regs" is and why exactly such > an exception in stack state tracking is made where only operations to SP are > taken into account.
"regs" is a special type of stack frame, usually for asm entry code, where the frame is actually an instance of 'struct pt_regs'. So if there's a variable associated it with it, maybe it should have "regs" in the name.
Though I think non-x86 arches will also have regs frames, so would it make sense to just make the unwind hint types a global multiarch thing? They could be renamed to UNWIND_HINT_TYPE_REGS{_PARTIAL}. Then there wouldn't really be a need for the "sp_only" thing.
-- Josh
| ![\](/images/icornerr.gif) |