This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]