Re: user instruction tracing patch?

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Fri, 2007-11-16 at 12:16 -0500, Frank Ch. Eigler wrote:
> jkenisto wrote:
> 
...
> 
> >[...]
> > But wouldn't real-life scripts be just as likely to do something like
> >   probe program("PATHNAME").pid(TBD).function("NAME") { ... }
> > [...]
> >   probe program("PATHNAME").descendent_of($1 /*pid*/).function("NAME")
> 
> One can get carried away with encoding too much in the probe point
> syntax.

Yeah, I wasn't proposing that as actual syntax.  The point is that
  probe program("PATHNAME").function("NAME") { ... }
provides everything stap needs to establish the probepoint and handler,
except the pid; and in many cases (it seems to me) the pid(s) won't be
known until after staprun starts (-c and -x notwithstanding).  So how do
we plug in the pid when we enable the probe?

> Generally, they are meant to be statically resolvable sorts
> of things identifying the parts of the system possibly being affected
> by probing.  I'd like to add dynamic things only tastefully - if they
> are common, compact, obvious; if translator/runtime automation
> significantly assists performance or safety; if they cannot be
> reasonably coded up in plain script code.

I'm not sure of the intent of that last phrase.  I assume we don't want
stap scripts to have to resort to embedded C with explicit calls to
[un]register_u[ret]probe() and such.

> > The above suggests (to me, anyway) that we should either:
> > 1) support probe enablement via a statement in a probe handler [...]
> > 2) expand the probe statement syntax to accommodate same.
> 
> You may be mixing things up.  The two alternate syntaxes for
> on-the-fly probe enable/disable operations are roughly equally capable
> in this regard.  (If it takes script code to determine enablement,
> then that script code could just as easily use either activating
> variables or function calls.)

Sure.  But again, I think that we will see cases where the pid/tid can't
be encoded in the static probe definition, and must be specified on the
fly.  I'd like to see that taken into consideration when we're
discussing syntax alternatives.

> 
> 
> - FChE

Jim