Re: user instruction tracing patch?

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

On Wed, 2007-11-14 at 22:58 -0500, Frank Ch. Eigler wrote:
> Hi, Roland -
> 
> On Wed, Nov 14, 2007 at 03:38:25PM -0800, Roland McGrath wrote:
> 
> > [...]  What I find opaque in a way I don't like is the idea that I
> > might need to go through every probe and function body looking for
> > things that might modify "foo" to know when that means "trigger
> > enabling/disabling itrace", [...]
> 
> But there wouldn't be that many probes in an ordinary hand-written
> script.  Most fit on a page or two, so finding the control variables
> would be doable "by inspection".
> 
> - FChE

I think it would help if we were clear on the sorts of probing we expect
SystemTap to support as it exploits utrace, uprobes, and instruction
tracing (AKA itrace).

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.

I often see examples like
  probe process(PID).function("NAME") { ... }

But wouldn't real-life scripts be just as likely to do something like
  probe program("PATHNAME").pid(TBD).function("NAME") { ... }
where PATHNAME specifies the a.out file (w/ dwarf info) and the PID is
somehow specified on the fly -- e.g., after fork and exec probes have
been triggered courtesy of utrace?

Similarly, you'd often want to specify a process ID or (more likely) a
thread/task ID when enabling a utrace- or itrace-based probe.

I can even envision things like
  probe program("PATHNAME").descendent_of($1 /*pid*/).function("NAME")

The above suggests (to me, anyway) that we should either:
1) support probe enablement via a statement in a probe handler, as
Roland and Dave N. suggested (so that pid or tid can be computed and
specified on the fly); or
2) expand the probe statement syntax to accommodate same.

Jim