15:23 <irker860> systemtap: alizhang systemtap.git:master * release-4.4-125-ge57668deb / tapsets.cxx testsuite/buildok/floatingpoint.stp: PR13838: support fp32_to_fp64 conversion automatically at functioncall synthesize level.

18:56 <ggherdov> Hello, not really a systemtap question, but close. With just the kprobe infrastructure, is there a straightforward way to attach a kprobe to a static tracepoint?

18:56 <ggherdov> AFAIU, krpobes can be attached to function+offset, so when I do, say, stap -e 'probe kernel.trace("sched:sched_switch"){...}' then it's systemtap who's doing something that with basic kprobes can't be easily done?

19:01 <fche> ggherdov, why a kprobe per se?

19:02 <fche> if you can find the call site of a tracepoint (and there can be multiple with the same name), you can definitely inject kprobes there, e.g. via probe kernel.statement("function@file.c:line") {}

19:03 <fche> though the point of tracepoints is to make it lighter weight then kprobes (subroutine calls instead of int3 exceptions)

19:15 <ggherdov> fche: right. It was more to verify I understand kprobes. You confirm that I need the explicit callsites for plain kprobes. If I want to run code at tracepoints (without looking for all callsites etc), I need systemtap for that.

19:15 <ggherdov> I'm trying to read some extra MSR when the tracepoint power:cpu_frequency hits, likely my best bet is systemtap with embedded C

19:17 <fche> hm yeah I don't think perf can attach that kind of information gathering to tracepoints

19:17 <fche> and don't worry about kprobes per se vs.

19:17 <fche> just probe kernel.trace("what:ever") { value = do_msr() println(value) } function do_msr() %{ /* c code */ %}

19:18 <fche> 'that uses the tracepoint api rather than kprobes, and will work just fine

19:19 <ggherdov> right, thanks