Re: [PATCH] decode_stacktrace: Support heuristic caller address search

[Google]

On Thu, 5 Mar 2026 15:56:13 +0100
Matthieu Baerts <matttbe@xxxxxxxxxx> wrote:

> Hi Masami,
> 
> On 05/03/2026 06:12, Masami Hiramatsu (Google) wrote:
> > From: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> > 
> > Add -c option to search call address search to decode_stacktrace.
> > This tries to decode line info backwards, starting from 1byte before
> > the return address, and displays the first line info it founds as
> > the caller address.
> > If it tries up to 10bytes before (or the symbol address) and still
> > can not find it, it gives up and decodes the return address.
> 
> Thank you for this new option!
> 
> > With -c option:
> >  Call Trace:
> >   <TASK>
> >   dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
> >   lockdep_rcu_suspicious (kernel/locking/lockdep.c:6876)
> >   event_filter_pid_sched_process_fork (kernel/trace/trace_events.c:1057)
> >   kernel_clone (include/trace/events/sched.h:396 include/trace/events/sched.h:396 kernel/fork.c:2664)
> >   __x64_sys_clone (kernel/fork.c:2795 kernel/fork.c:2779 kernel/fork.c:2779)
> >   do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> >   ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> >   ? trace_irq_disable (include/trace/events/preemptirq.h:36)
> >   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> > 
> > 
> > Without -c option:
> >  Call Trace:
> >   <TASK>
> >   dump_stack_lvl (lib/dump_stack.c:122)
> >   lockdep_rcu_suspicious (kernel/locking/lockdep.c:6877)
> >   event_filter_pid_sched_process_fork (kernel/trace/trace_events.c:?)
> >   kernel_clone (include/trace/events/sched.h:? include/trace/events/sched.h:396 kernel/fork.c:2664)
> >   __x64_sys_clone (kernel/fork.c:2779)
> >   do_syscall_64 (arch/x86/entry/syscall_64.c:?)
> >   ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> >   ? trace_irq_disable (include/trace/events/preemptirq.h:36)
> >   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> That's better indeed!
> 
> Do we need a new option for that? Could it not be the new default
> behaviour? Or are there any downsides with it?

AFAIK, this may not work well on the architectures which have delay
slot (I have not tested) which will execute one more instruction
after branch before branching. In that case, the return address will
not be the next instruction of the delay slot.
But I think that is not popular anymore, so we can switch the default
behavior and maybe we can switch it based on architecture.

Thank you,

> 
> "addr2line" will be called more, but if it is worth it, it is probably
> not an issue, or is it?
> 
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.
> 


-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>