Re: user instruction tracing patch?

["Frank Ch. Eigler" <fche at redhat dot com>]

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.


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

Maybe the example at the bottom makes this more clear.

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

Of course we don't.


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

> 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"); }

These two alternative cases have in common that the logic that
determines whether the "malloc" probe should be enabled is itself
first-class *script code*.  The interesting_p() function can perform
the "shares-ancestry-with -c/-x program" test if desired.  This is
what I was talking about with the "if they cannot be reasonably coded
up in plain script code" line above.


This can be contrasted with how one might implement

   probe program("/bin/vi").function("malloc") { .... }

in terms of uprobes/utrace at all, which operate at the PID level.
Without the runtime providing execname->tid mappings, and some
hidden-from-script machinery to dynamically add/remove uprobes, a user
might have to do something awful like this:

   probe process("*").function("malloc") if (vi_p) { .... }
   probe scheduler.cpu_on { vi_p = (execname() == "/bin/vi") }

And even that relies on fictional wildcarded PIDs, so never mind.
Choosing the "enable" syntax above *makes no difference at all* in
this.  Rather, this is the sort of probe point syntax that I think we
should have language-level support for: where expressing it with
existing mechanisms is just too approximate or painful.


- FChE