Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string
From: Ingo Molnar
Date: Tue Jan 24 2017 - 03:22:44 EST
* Ravi Bangoria <ravi.bangoria@xxxxxxxxxxxxxxxxxx> wrote:
>
>
> On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
> > * Alexis Berlemont <alexis.berlemont@xxxxxxxxx> wrote:
> >
> >> Hi Masami,
> >>
> >> Many thanks for your mail.
> >>
> >> Here is another patch set which tries to fix the points you mentioned:
> >>
> >> * Skip the arguments containing a constant ($123);
> >> * Review the code in charge of the register renaming (search for '%'
> >> and parse it);
> >> * Minor changes (print the argument in case of error, skipping, check
> >> the sdt arg type index);
> >>
> >> Many thanks,
> >>
> >> Alexis.
> >>
> >> Alexis Berlemont (2):
> >> perf sdt: add scanning of sdt probles arguments
> >> perf probe: add sdt probes arguments into the uprobe cmd string
> > I'd like to hijack this thread to report an SDT oddity - one of my boxen reports
> > lots of SDT tracepoints in 'perf list':
> >
> > mem:<addr>[/len][:access] [Hardware breakpoint]
> >
> > sdt_libc:lll_lock_wait_private [SDT event]
> > sdt_libc:longjmp [SDT event]
> > sdt_libc:longjmp_target [SDT event]
> > sdt_libc:memory_arena_new [SDT event]
> > sdt_libc:memory_arena_retry [SDT event]
> > sdt_libc:memory_arena_reuse [SDT event]
> > sdt_libc:memory_arena_reuse_free_list [SDT event]
> > sdt_libc:memory_arena_reuse_wait [SDT event]
> > sdt_libc:memory_calloc_retry [SDT event]
> > sdt_libc:memory_heap_free [SDT event]
> > ...
> >
> > But none of them work:
> >
> > Error: No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp
> > Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
> >
> > ...
> >
> > Error: File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
> > Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
> >
> > What kind of patches are required for SDT probes to work?
>
> Hi Ingo,
>
> I suppose you are trying to record SDT events without probing it.
> In that case, first put a probe on an event and then try to record
> it. For example,
Well, I was mainly complaining about the misleading messages and flow of the
tooling here. Could you please improve the messages so that if I use it like the
way I reported it results in me trying the right approach?
Thanks,
Ingo