Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

From: Ravi Bangoria
Date: Tue Jan 24 2017 - 03:36:44 EST

On Tuesday 24 January 2017 01:52 PM, Ingo Molnar wrote:
> * 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?

Right, message is misleading. Will prepare a patch for this.

Also it's little odd flow for sdt markers, to put a probe first and then
record it while other events can be recorded directly. There was a
patch by Hemant about directly recording SDT marker events. I
don't see any updates on that:


> Thanks,
> Ingo