Re: user instruction tracing patch?

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

On Fri, 2007-11-16 at 14:20 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> On Fri, Nov 16, 2007 at 11:36:11AM -0800, Jim Keniston wrote:
> 
> > [...]  probe program("PATHNAME").function("NAME") { ... } provides
> > everything stap needs to establish the probepoint and handler,
> > except the pid [...] So how do we plug in the pid when we enable the
> > probe?
> 
> See at the bottom.
...
> 
> > 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.
> 
> But that issue is separate from the syntax alternatives for on-the-fly
> enablement being discussed.  Here they are, doing something like
> "activate the malloc probe for the first 300 ms within an interesting
> thread".
> 
> 
> (a - being implemented):
> 
>    probe program("/bin/vi").function("malloc") if (mp) { .. }
>    probe syscall.fork.return { if (interesting_p(pid))  mp = 1 }
>    probe timer.ms(300) { mp = 0 }
> 
> (b - roland's proposal):
> 
>    probe program("/bin/vi").function("malloc") { ... }
>    probe syscall.fork.return { if (interesting_p(pid))
>                          enable program("/bin/vi").function("malloc"); }
>    probe begin,timer.ms(300) { disable program("/bin/vi").function("malloc"); }

Well, Frank's syntax is prettier in this example.  I had assumed that
Roland's approach included some way to name a probe, so that the enable
statement/function could use that instead of the explicit probe
specification.  As a script evolves during a debugging session, it's
certainly possible for it to accumulate more than one handler for the
same probepoint, so the explicit probe specification would be ambiguous.
Frank's syntax avoids that ambiguity.

But what both examples assume is that a task can dynamically
enable/disable probes only for itself (in the case of utrace/itrace) or
its own process (uprobes).  The underlying kernel facilities don't
impose this constraint.  I expect that self-probing (so to speak) covers
the vast majority of cases, and I'm happy to see you start with that,
but it'll be interesting to see whether a need for "cross-probing"
develops.

...
> 
> 
> - FChE

Jim