Individual Probe States

[Mark Wielaard <mjw at redhat dot com>]

Hi,

We have grown a lot of different probe handlers over the years. While
working on the user/kernel backtrace stuff it has been a little
confusing at times what state is really available depending on which
probe handler fired. A couple of probe handlers have context fields in
which they put specific data associated with the handler. So checking
some of these fields could tell us a bit more about the actual context
available (user/kernel context, registers, u/kretprobe handlers, etc.)

What I have done is tried to document all the (low-level) handlers we
have, make explicit in the CONTEXT which one is currently "life", and
moved all individual probe state into one union (to safe space and make
it easier to just clear it all on entry). [In some earlier commits I
also cleaned up and shrunk the context a little, but I think those
cleanups weren't controversial.]

This will make things a little easier for the backtrace code, since it
has a more explicit view of the current probe context. Hopefully it is
not completely insane and also useful to other runtime code. If this
totally destroys the runtime context code please yell and scream. Also
please look over the descriptions/comments I added for the various
handlers. Maybe I misunderstood some. And maybe some more context could
be moved into the "ips". Originally I thought the "type" should be part
of the probe instead of passing it to common_probe_entryfn_prologue ()
as string. But I got a little confused about where in the hierarchy it
should go (probe, probe_point, derived_probe). So any
clarification/cleanup of that part would be helpful too.

The various probe handlers that we now distinguish:

/* begin, end or never probe, triggered by stap module itself. */
#define _STP_PROBE_HANDLER_BEEN            1
/* user space instruction probe, trigger by utrace signal report. */
#define _STP_PROBE_HANDLER_ITRACE          2
/* kernel marker probe, triggered by old marker_probe (removed in 2.6.32). */
#define _STP_PROBE_HANDLER_MARKER          3
/* perf event probe, triggered by perf event counter.
   Note that although this is defined in tapset-perfmon.cxx, this has
   nothing to do with the (old and now removed) perfmon probes. */
#define _STP_PROBE_HANDLER_PERF            4
/* read or write of stap module proc file. Triggers on manipulation of
   the /proc/systemtap/MODNAME created through a procfs probe. */
#define _STP_PROBE_HANDLER_PROCFS          5
/* timer probe, triggered by standard kernel init_timer interface. */
#define _STP_PROBE_HANDLER_TIMER           6
/* high resolution timer probes, triggered by hrtimer firing. */
#define _STP_PROBE_HANDLER_HRTIMER         7
/* profile timer probe, triggered by kernel profile timer (either in
   kernel or user space). */
#define _STP_PROBE_HANDLER_PROFILE_TIMER   8
/* utrace thread start/end probe, triggered by utrace quiesce event for
   associated thread. */
#define _STP_PROBE_HANDLER_UTRACE          9
/* utrace syscall enter/exit probe, triggered by utrace syscall event. */
#define _STP_PROBE_HANDLER_UTRACE_SYSCALL 10
/* kprobe event, triggered for dwarf or dwarfless kprobes. */
#define _STP_PROBE_HANDLER_KPROBE         11
/* kretprobe event, triggered for dwarf or dwarfless kretprobes. */
#define _STP_PROBE_HANDLER_KRETPROBE      12
/* uprobe event, triggered by hitting a uprobe. */
#define _STP_PROBE_HANDLER_UPROBE         13
/* uretprobe event, triggered by hitting a uretprobe. */
#define _STP_PROBE_HANDLER_URETPROBE      14
/* hardware data watch break point, triggered by kernel data read/write. */
#define _STP_PROBE_HANDLER_HWBKPT         15
/* kernel tracepoint probe, triggered by tracepoint event call. */
#define _STP_PROBE_HANDLER_TRACEPOINT     16

The commits:

commit 6dceb5c9bd2848c9bddde19d881444b7df8bee1d
Author: Mark Wielaard <mjw@redhat.com>
Date:   Wed Aug 3 11:17:00 2011 +0200

  common_probe_context.h: Put Individual Probe State (ips) into a union.
    
  Various probe handlers have dedicated fields in the common probe context
  struct. Since the handlers cannot be active at the same time (on the same
  cpu) these can just be put into a union to save space. In runtime code
  when there might be ambiguity about which probe handler is running, the
  CONTEXT->probe_type field can be used to check which field has actual
  life data.

commit 6eefe9428f47a767f6a504dddb8f385d6896ccf3
Author: Mark Wielaard <mjw@redhat.com>
Date:   Tue Aug 2 16:42:38 2011 +0200

  Add probe_type to common probe context.
    
  This exposes the type of probe handler for use in runtime functions,
  so they can better anticipate which common probe context is valid at
  runtime. Also introduces a new context tapset function probe_type()
  that exposes a (informational) probe handler string to scripts. Mainly
  useful for debugging, when the user wants to find out which kind of
  low level probe handler a high-level probe translates to for a particular
  kernel/systemtap version.

Cheers,

Mark