This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes


I took a good look at the current bits, and there are a few more things 
that need to be fixed before we can consider 'perf probe' for upstream.

Firstly, this decoder bug is still not fixed:

  CHK     include/linux/compile.h
  TEST    posttest
Error: ffffffff81068fe0:        66 0f 73 fd 04          pslldq $0x4,%xmm5
Error: objdump says 5 bytes, but insn_get_length() says 4 (attr:8000)
make[1]: *** [posttest] Error 2

64-bit allyesconfig will trigger this for example, but the attached 
smaller config too. This needs to be fixed before we can apply any
new commits.

Secondly, the probe syntax is quite non-obvious currently. All the 'p' 
and -P gymnastics is just a barrier to the first-time user getting his 
first probe inserted successfully.

The user need not worry about whether it's a 'kprobe' or a 'kretprobe'. 
The user should _specify_ what it wants to probe, and _that_ will lead 
to 'perf probe' picking the most suitable facility to achieve that kind 
of probing.

It might be a kprobe, a kretprobe, or an mcount driven function probe, 
an existing tracepoint if it happens to be present in that place already 
- or some other future mechanism. The driving force must be a robust 
specification of 'what', not the mechanics of 'how'.

Considering that, the current 'perf probe' syntax does not achieve that 
goal yet.

Here are a few syntax suggestions

The simpest probe syntax should be to add a probe to a single function 
name:

  perf probe +schedule

_nothing else_.

To remove it, the user should just do something like:

  perf probe -schedule

(to be symmetric 'perf probe +schedule' should work as well)

perf probe will make up a synthetic probe name for that - probe-1 for 
example. It will also pick the suitable probe mechanism (kprobes).

All the other extensions and possibilities - arguments, variables, 
source code lines, etc. should be natural and intuitive extensions of 
this basic, minimal syntax.

To insert a simple probe no -P should be needed, 'p', no ':' - no probe 
name even.

Furthermore, there should be a way to list existing probes (and only 
probes), probably via 'perf list --probes' or 'perf probe --list'.

Plus, 'perf probe --help' should list a few simple examples, beyond the 
syntax.

Ok?

	Ingo

Attachment: config
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]