This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Forw: state of the translator
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: systemtap at sources dot redhat dot com
- Date: 04 Aug 2005 12:08:49 -0400
- Subject: Forw: state of the translator
From: graydon hoare <graydon@redhat.com>
Date: Wed, 3 Aug 2005 20:19:00 -0700
hi,
as of this evening, I can point out a few things which work in the
translator and a few notable things which do not. one could argue that
we have a tool which can be used for real diagnostic work now; but
it's still very fragile, and still has lots of incomplete parts.
working
~~~~~~~
- typing in a .stp script, running "stap foo.stp", and watching the
output from the kernel you're working on -- the "end-to-end"
process -- works for the limited sort of scripts described below.
- the kernel.function("foo*") probes fire on the first instruction
after the prologue of the function(s) matching the pattern. this is
the most obvious form of probe a user will want to write.
- reading a scalar value $foo from target space works inside a probe,
including the parameters of a function you're probing.
- functions (and probes) in library directories full of .stp files
work; these can define systemtap-language functions, or functions
which contain literal C code which passes through to the module, so
it's easy to add routines which access other kernel facilities.
- basic array reading, writing and "foreach" iterating works, for up
to 5 dimensions and scalar values.
- builtin functions are provided for dumping data out of the probes:
log() and warn() talk to stpd; printk() talks to dmesg; string()
and hexstring() format numbers as strings for printing.
- kernel.function("foo").return probes are supposed to be working,
but I have not personally tested them so I can't say. frank added
this recently.
non-working
~~~~~~~~~~~
- the module("foo").function("bar") patterns only occasionally work
at the translation stage (when they do it's pure luck) and they do
not work at the compilation stage: we emit nonsense code into the
kernel module because we haven't determined what technique to use
for resolving from a module-relative address to a global one. this
might start working soon, because it's not deeply or theoretically
broken. it's just practically broken. we need to decide what code
to generate, and figure out what if anything is wrong with the
dwarf info in the kernels we're testing.
- writing to any target variables (modifying kernel state) does not
work at all. it's trapped in the translator and an error is printed.
- reading from structure-pointer-member target variables does not work
(no $foo->bar access). as far as I know we don't even *parse* this,
or if we do we don't get much beyond that.
- the "in" and "delete" operators on arrays are unimplemented;
they're small but I got sidetracked into target variable access
before finishing them.
- the <<< operator doesn't, as far as I know, work. neither do
statistic-valued arrays, or anything related to statistics.
- local arrays don't work. only global arrays (arguably this is
not a huge problem since you can't pass arrays as arguments to
functions anyways, a purely local array isn't all that useful)
- the .label("foo"), .relative(NNN), and .callees probe types are
all unimplemented.
- locking kernel modules in place during probe execution is not
done. this is a crucial safety issue before we can say that
modules are "working".
- of course, probing user-space is not even attempted. there's
nothing related to it in there yet.
- probing all instances of inline functions or macros is not
supported.
- probing static functions by name is not supported; I do not know
if this will ever be possible because I don't know if the
function names are tossed into the dwarf info.
- probing based on source line numbers is implemented but has not
been tested so it should be assumed to be not working.
-graydon