static defined user probes

[Stan Cox]

Here is an implementation of statically defined user probes which use
uprobes probes.  The test, testsuite/systemtap.base/sduprobes.{c,stp}
give a brief synopsis of the user interface.  (sduprobes.exp is not
completely fleshed out yet.) Currently STAP_PROBE_START turns on probing
and STAP_PROBEN define probe points.  STAP_PROBEN are defined the same
as DTRACE_PROBEN and give the name of the probe and the arguments to the
probe.  These macros are defined in sduprobes.h. The name of the probe
given to STAP_PROBEN is the label given to process(PROC).mark("LABEL").
Currently the landing pad for the probes is in sduprobes.c; this routine
is built with debugging turned on and is in the library libsduprobes.a.
The goal, ultimately, is for this to be a shared library.  There can be
a many to one relationship between the STAP_PROBEN probes and the
landing pad, so a .probes section is created which stap uses to
determine the proper corresponding  probe point.  For example there may
be multiple uses of STAP_PROBE2, which uses stap_probe_2 as a landing
pad.  The .probes section is a list of the probe labels and the number
of arguments corresponding to that probe.  Running the application
without probling should have little or no impact.  Currently the support
for this is somewhat minimal.  The probes are defined using
__builtin_expect but a test is executed and a call is present.  The
__builtin_expect checks a sentinel value that is currently set via
setting the environment variable SYSTEMTAP_SDUPROBES.  It is desirable
to have stap be able to turn this off and on without the use of an
environment variable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sduprobes.patch
Type: text/x-patch
Size: 13463 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20081112/ae70688e/attachment.bin>