systemtap точки зондирования (systemtap probe points)
Синтаксис (Syntax)
probe PROBEPOINT [, PROBEPOINT] { [STMT ...] }
A probe declaration may list multiple comma-separated probe
points in order to attach a handler to all of the named events.
Normally, the handler statements are run whenever any of events
occur. Depending on the type of probe point, the handler
statements may refer to context variables (denoted with a dollar-
sign prefix like $foo) to read or write state. This may include
function parameters for function probes, or local variables for
statement probes.
The syntax of a single probe point is a general dotted-symbol
sequence. This allows a breakdown of the event namespace into
parts, somewhat like the Domain Name System does on the Internet.
Each component identifier may be parametrized by a string or
number literal, with a syntax like a function call. A component
may include a "*" character, to expand to a set of matching probe
points. It may also include "**" to match multiple sequential
components at once. Probe aliases likewise expand to other probe
points.
Probe aliases can be given on their own, or with a suffix. The
suffix attaches to the underlying probe point that the alias is
expanded to. For example,
syscall.read.return.maxactive(10)
expands to
kernel.function("sys_read").return.maxactive(10)
with the component maxactive(10) being recognized as a suffix.
Normally, each and every probe point resulting from wildcard- and
alias-expansion must be resolved to some low-level system
instrumentation facility (e.g., a kprobe address, marker, or a
timer configuration), otherwise the elaboration phase will fail.
However, a probe point may be followed by a "?" character, to
indicate that it is optional, and that no error should result if
it fails to resolve. Optionalness passes down through all levels
of alias/wildcard expansion. Alternately, a probe point may be
followed by a "!" character, to indicate that it is both optional
and sufficient. (Think vaguely of the Prolog cut operator.) If
it does resolve, then no further probe points in the same comma-
separated list will be resolved. Therefore, the "!" sufficiency
mark only makes sense in a list of probe point alternatives.
Additionally, a probe point may be followed by a "if (expr)"
statement, in order to enable/disable the probe point on-the-fly.
With the "if" statement, if the "expr" is false when the probe
point is hit, the whole probe body including alias's body is
skipped. The condition is stacked up through all levels of
alias/wildcard expansion. So the final condition becomes the
logical-and of conditions of all expanded alias/wildcard. The
expressions are necessarily restricted to global variables.
These are all syntactically valid probe points. (They are
generally semantically invalid, depending on the contents of the
tapsets, and the versions of kernel/user software installed.)
kernel.function("foo").return
process("/bin/vi").statement(0x2222)
end
syscall.*
syscall.*.return.maxactive(10)
syscall.{open,close}
sys**open
kernel.function("no_such_function") ?
module("awol").function("no_such_function") !
signal.*? if (switch)
kprobe.function("foo")
Probes may be broadly classified into "synchronous" and
"asynchronous". A "synchronous" event is deemed to occur when
any processor executes an instruction matched by the
specification. This gives these probes a reference point
(instruction address) from which more contextual data may be
available. Other families of probe points refer to
"asynchronous" events such as timers/counters rolling over, where
there is no fixed reference point that is related. Each probe
point specification may match multiple locations (for example,
using wildcards or aliases), and all them are then probed. A
probe declaration may also contain several comma-separated
specifications, all of which are probed.
Brace expansion is a mechanism which allows a list of probe
points to be generated. It is very similar to shell expansion. A
component may be surrounded by a pair of curly braces to indicate
that the comma-separated sequence of one or more subcomponents
will each constitute a new probe point. The braces may be
arbitrarily nested. The ordering of expanded results is based on
product order.
The question mark (?), exclamation mark (!) indicators and probe
point conditions may not be placed in any expansions that are
before the last component.
The following is an example of brace expansion.
syscall.{write,read}
# Expands to
syscall.write, syscall.read
{kernel,module("nfs")}.function("nfs*")!
# Expands to
kernel.function("nfs*")!, module("nfs").function("nfs*")!
