* static probes
@ 2006-03-30 15:43 Frank Ch. Eigler
2006-03-31 4:29 ` Jose R. Santos
0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2006-03-30 15:43 UTC (permalink / raw)
To: systemtap
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: static probes
2006-03-30 15:43 static probes Frank Ch. Eigler
@ 2006-03-31 4:29 ` Jose R. Santos
2006-03-31 4:43 ` Frank Ch. Eigler
0 siblings, 1 reply; 3+ messages in thread
From: Jose R. Santos @ 2006-03-31 4:29 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: static probes
2006-03-31 4:29 ` Jose R. Santos
@ 2006-03-31 4:43 ` Frank Ch. Eigler
0 siblings, 0 replies; 3+ messages in thread
From: Frank Ch. Eigler @ 2006-03-31 4:43 UTC (permalink / raw)
To: Jose R. Santos; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-03-31 4:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-30 15:43 static probes Frank Ch. Eigler
2006-03-31 4:29 ` Jose R. Santos
2006-03-31 4:43 ` Frank Ch. Eigler
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).