static probes

static probes

[Frank Ch. Eigler]

Hi -

I committed a part of a prototype for static instrumentation macros,
from <http://sourceware.org/ml/systemtap/2005-q4/msg00415.html>.

To use it, #include "stapmark.h" in your kernel or module source file
of choice, and add macro calls of this form to any old spot:
  STAP_MARK_<typesig>(name,arg1,...)
For example, in kernel/sched.c (context_switch), around the 
the switch_to() call, you can plop
  STAP_MARK_NN(context_switch,next->pid,prev->pid);
Then recompile your module or kernel as needed.
(The <typesig> identifies each argument type: "N" = int64_t number,
"S" = const char * string.  The name field is any reasonably unique
identifier.)

When not used by an active systemtap probe, these markers cost very
little (I'll quantify it for the OLS paper), so theoretically they can
be sprinkled around generously.  When used by an active systemtap
probe, the cost is much smaller than a kprobe in the same place -
something like a djprobe.

To place a probe on such a marker, the CVS systemtap now understands
    probe kernel.mark("name") { ... }
or  probe module("m").mark("name") { ... }
Wildcards in the names are supported as usual.  For these probes,
systemtap does NOT require/use debugging information, so we're not
at the mercy of gcc.

The above works, and seems to not crash during gentle testing.  The
instrumentation macros should not need to change incompatibly, so you
can theoretically go ahead and add markers without having to redo it later.

This draft has a couple of shortcomings:

- The arguments passed at the STAP_MARK macro are not yet available to the
  script-side probe handler, but will soon be $arg1, etc.
- The translator parses /proc/kallsyms and /boot/System.map to fetch the
  kernel/module symbol tables, until elfutils gets a handy API (bug #2461).
- Concurrent use of the same markers from multiple probes/sessions is
  not supported, and is not completely protected against by the
  translator-generated setup/teardown code.
- Oops, forgot support for zero-argument markers.  Will fix pronto.


- FChE

Re: static probes

[Jose R. Santos]

Frank Ch. Eigler wrote:

>To place a probe on such a marker, the CVS systemtap now understands
>    probe kernel.mark("name") { ... }
>or  probe module("m").mark("name") { ... }
>Wildcards in the names are supported as usual.  For these probes,
>systemtap does NOT require/use debugging information, so we're not
>at the mercy of gcc.
>  
>
Sounds interesting.  Would it be possible for SystemTap to check for the 
availability of a static probe before reverting to kprobing a kernel 
function?  The reason I ask is that for LKET, fast static probe that can 
be inserted anywhere  would be useful for our trace hooks, but if the 
kernel lack a particular static probe but the same probe can dynamically 
iinserted, then we can use the alternative dynamic probe with out 
requiring changes to the LKET code to handle both scenarios.

-JRS

Re: static probes

[Frank Ch. Eigler]

Hi -

jrs wrote:

> [...]  Would it be possible for SystemTap to check for the
> availability of a static probe before reverting to kprobing a kernel
> function?  [...]

That is, have systemtap substitute a function/statement() probe with a
mark() probe if one happens to be nearby?  It may be possible, though
the mapping is not exact.  For example, pt_regs* would not be
conveniently available in the latter case, so arbitrary $target
variables could be unavailable.

- FChE