what does 'probe process(PID_OR_NAME).clone' mean?

[David Smith <dsmith at redhat dot com>]

I started an internal systemtap conversation that I should have started
here, so I'm going to forward on my original email and Roland's response
to this list.

===

I've been working on solving the bug 6500 fallout and that seems to be
working now (changes just checked in).  However, the changes have
either changed behavior or caused a bug, depending on your point of view.

It all boils down to what does "probe process(PID_OR_NAME).clone" mean?
Or perhaps more precisely, when does "probe process(PID_OR_NAME).clone"
get called?

Here's an example.  If you do 'probe process("/bin/bash").clone', your
probe will get called once whenever /bin/bash calls fork() (or gets
fork()'ed).  In the case of path based probing, the distinction of
calling fork() or getting fork()'ed doesn't really matter - the probe
will get called once either way.

However, in the case of pid based probing, the distinction does matter.
If you do 'probe process(12345).clone', when should that probe get
called?  Should:

(A) the pid 12345 .clone probe get called when pid 12345 calls fork()?

or

(B) the pid 12345 .clone probe get called when a pid 12345 gets created?

With what was originally checked in, (A) is true (so test UTRACE_P5_05
passes).  When the new 6550 fallout changes, (B) is true (so test
UTRACE_P5_05 fails).

At first I thought the new (B) behavior was a bug, but I've talked
myself into believing (B) is the correct behavior.

Note that a behavior very similar to (A) could return when bug #6445
(probe process PID and its descendents) gets implemented.  Behavior (A)
also seems more like a syscall-based probe that only looks at clone calls.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)