Re: [PATCH] objtool: Fix STACK_FRAME_NON_STANDARD reloc type

[Masami Hiramatsu <mhiramat@kernel.org>]

On Mon, 2 May 2022 10:59:21 -0700
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Sat, Apr 30, 2022 at 01:44:00PM +0200, Peter Zijlstra wrote:
> > > > I also don't see any kprobe/optprobe hooks in unwind.h, so what happens
> > > > if we hit an optprobe?
> > > 
> > > Same as for any other generated code, the unwinder will try to fall back
> > > to frame pointers, and if that doesn't work, the unwind stops.
> > > 
> > > That commit didn't change anything since it was already not being
> > > directly executed anyway, but rather used to generate code on the fly.

Ah, OK. So ORC will not work on the dynamically generated trampoline code.
Can we generate ORC information entry dynamically?
(E.g. copying ORC data from the original code)

> > > 
> > > And before that commit it was being ignored by ORC anyway, thanks to
> > > STACK_FRAME_NON_STANDARD.  Which can now be removed since this code is
> > > now data and objtool will no longer try to understand it.
> > 
> > Right; but I suppose I'm wondering if we should fix this. It seems a
> > rather sub-optimal state of affairs.
> 
> Masami recently fixed some kprobes ORC issues but I don't know if this
> one was fixed.

I've fixed the kretprobe ORC unwinder issue. I need to check the optprobe
case too.

> 
> As to the whether it's worth fixing, I dunno.  There are trade offs.
> 
> Depends on how common the stack trace is -- I'm guessing not very, since
> I've never seen a bug report -- and how important it is to get to full
> ORC coverage.  If our goal is full coverage, we'd need a way for
> generated code to add/remove ORC entries.

Agreed, if I can copy the ORC entries for the original code to the entries
for generated code, I can fix it.

Thank you,


> 
> -- 
> Josh
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>