Re: user instruction tracing patch?

[fche@redhat.com (Frank Ch. Eigler)]

jkenisto wrote:

> [...]  For example, will stap provide access to all the
> task-lifetime events that utrace reports (on a per-task basis, BTW)
> -- fork/clone, exec, exit, signal, syscall, etc?  I hope so.

These sound sensible.  It could be interesting to use utrace's system
call interception facilities instead of the system-wide ones we were
discussing yesterday, when the focus can be appropriately restricted.

>[...]
> 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.  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.

> 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.)


- FChE