On Tuesday 24 January 2017 01:52 PM, Ingo Molnar wrote: > * Ravi Bangoria <ravi.bango...@linux.vnet.ibm.com> wrote: > >> >> On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote: >>> * Alexis Berlemont <alexis.berlem...@gmail.com> 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: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1138183.html -Ravi > Thanks, > > Ingo >
