Messages in this thread | | | Date | Thu, 30 Oct 2008 22:30:18 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [PATCH] ftrace: distinguish kretprobe'd functions in trace logs |
| |
On Wed, 28 May 2008, Abhishek Sagar wrote: > Hi Steven, > > Tracing functions via ftrace which have a kretprobe installed on them, can produce misleading output in their trace logs. E.g, consider the correct trace of the following sequence: > > do_IRQ() > { > ~ > irq_enter(); > ~ > } > > > Trace log (sample): > <idle>-0 [00] 4154504455.781616: irq_enter <- do_IRQ > > > But if irq_enter() has a kretprobe installed on it, the return value stored on the stack at each invocation is modified to divert the return to a kprobe trampoline function called kretprobe_trampoline(). So with this the trace would (currently) look like: > > <idle>-0 [00] 4154504455.781616: irq_enter <- kretprobe_trampoline > > Now this is quite misleading to the end user, as it suggests something that didn't actually happen. So just to avoid such misinterpretations, the inlined patch aims to output such a log as: > > <idle>-0 [00] 4154504455.781616: irq_enter <- [unknown/kretprobe'd] > >
[...]
> + > +#ifdef CONFIG_KRETPROBES > +static inline int kretprobed(unsigned long addr) > +{ > + return addr == (unsigned long)kretprobe_trampoline;
Hi Abhishek,
Now that this code is in mainline, it has become apparent that kretprobe_trampoline is not defined on all archs as a global like it is in x86. This needs to be fixed (it breaks ia64 build).
Thanks,
-- Steve
> +} > +#else > +static inline int kretprobed(unsigned long addr) > +{ > + return 0; > +} > +#endif /* CONFIG_KRETPROBES */
| |