dtrace discuss - Oct 2007 - Translators and multiply defined probenames]

> I have a code that has several probes with the same probename.  When I
define the probe to use a translator and then try to match for all the
occurances of the probename in a D script I get the following error:
> 
> dtrace: invalid probe specifier mpi__test$target:::RECV_REQ_ACT_EV {
printf("%d %d", args[0]->bar, args[0]->baz); }: in action list:
args[ ] may not be referenced because probe description
mpi__test9055:::RECV_REQ_ACT_EV matches an unstable set of probes
> 
> However if I specify the function the probe exists in things work fine. 
Like so,
> 
> dtrace -c main -n ''mpi__test$target::recv_1:RECV_REQ_ACT_EV {
printf("%d %d", args[0]->bar, args[0]->baz); }''
> dtrace: description ''mpi__test$target::recv_1:RECV_REQ_ACT_EV
'' matched 1 probe
> dtrace: pid 9057 has exited
> CPU     ID                    FUNCTION:NAME
>   0  43963           recv_1:RECV_REQ_ACT_EV 1 2
> 
> My question is there a way that if these two probes with the same
> probename can be defined such that the failing case would work?  The
> reason I want to do this is in the case of MPI the probenames are
> Events and the certain events can be triggered in multiple places in
> the code.  I''d also would like to avoid requiring D script writers
to
> have to explicitly state which functions the probenames occur because I
> could see this possibly changing with time.
If you have multiple instrumentation sites for the probe RECV_REQ_ACT_EV,
and you want to allow people to instrument using the description:

mpi__test$target:::RECV_REQ_ACT_EV

independent of function and module (which is a good thing), then you need 
to do two things:

(a) Ensure that all RECV_REQ_ACT_EV sites pass the same arguments to
    the DTRACE_* macros that mark the probe locations, and

(b) Establish the appropriate provider stability, which is done by 
    #pragma D attributes after the provider foo { } declaration.
    Here is an example set of declarations from plockstat in libc:

#pragma D attributes Evolving/Evolving/ISA provider plockstat provider
#pragma D attributes Private/Private/Unknown provider plockstat module
#pragma D attributes Private/Private/Unknown provider plockstat function
#pragma D attributes Evolving/Evolving/ISA provider plockstat name
#pragma D attributes Evolving/Evolving/ISA provider plockstat args

    which is probably similar to what you want.  Notice that module are
    function are marked Private, whereas the other items are Evolving
    (i.e. mpi__test$target:::RECV_REQ_ACT_EV is a committed interface,
    whereas mpi__test$target::some_function_name:RECV_REQ_ACT_EV is not)

The rule for args[] and translators when the clause matches more than one
probe is that args[] and translators will *not* be available if either of
the following conditions is true:

1. The Arguments Data stability of the matched provider is less than Evolving.

2. Any description component that is at least Evolving is empty or is
   specified using a globbing expression.

These rules imply that providers that provide Evolving or better Arguments Data
stability must guarantee that all probes with identical field names in a field
of Evolving or better Name stability have identical argument signatures.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/