public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: systemtap@sources.redhat.com
Subject: static probes
Date: Thu, 30 Mar 2006 15:43:00 -0000	[thread overview]
Message-ID: <20060330154333.GM599@redhat.com> (raw)

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

             reply	other threads:[~2006-03-30 15:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-30 15:43 Frank Ch. Eigler [this message]
2006-03-31  4:29 ` Jose R. Santos
2006-03-31  4:43   ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060330154333.GM599@redhat.com \
    --to=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).