[dtrace-discuss] Hekp dtrace -l is bleeding Unstable implementation details all over my USDT probe namespace :(

[John Rice]

Hi,

As I've discussed before whenever we add USDT probes to a C++ function 
and call dtrace -l we get the mangled C++ name for the dtrace function, 
being listed :(

Now the point of USDT probes  is to abstract a higher level semantic 
construct for users to make use of. Surely it is not meant to be listing 
Unstable Interfaces (implementation details), such as the containing C++ 
mangled function. I know there's an argument that this is useful to list 
the location of USDT probes through out the code, but that's what the 
source is for :) This is particularly ugly in C++ due to the mangled 
names, but is equally problematic in C code as well, we are bleeding 
Unstable interfaces :(

Some examples:
$ dtrace -ln "moz*:::"

   ID   PROVIDER    MODULE   
FUNCTION                                                                                                             
NAME
  128 mozilla3516      libxul.so       
__1cKnsDocShellLEndPageLoad6MpnOnsIWebProgress_pnKnsIChannel_I_I_  
load-uri-start
Plain ugly me thinks :(

Some proposals:
We could do a few things.

1. For USDT probes by default have dtrace -l list Provider, Name only. 
This would hide the Unstable Interfaces of Module and Function.
2. Or you could argue that dtrace -l is the verbose listing so it 
continues to list the Provider, Module, Function and Name, but running 
dtrace on it's own without any params lists the probes Stable interfaces 
for you. You'd need to change the doc and reeducate folks, but that's 
certainly possible.

$dtrace "moz:::"
   ID   PROVIDER      NAME
  128 mozilla3516        load-uri-start

3. Allow the author of the probe to specify Stable interfaces for Module 
and Function in the USDT provider dtrace.d file.
provider mozilla {
 probe resource:mozdtrace_load_uri_start:load__uri__start(int *, char *);
    :
}
Now:
$ dtrace -ln "moz*:::"

   ID   PROVIDER       MODULE       FUNCTION                      NAME
  128 mozilla3516         resource            mozdtrace_load_uri_start  
load-uri-start

The assumption is that if they are called out in the provider then they 
are Stable and have dtrace -l only list Stable interfaces.

Current Hack:

Current hack of wrapping probe in extern "C" func to hide the Funcion 
implementation details:
   ID   PROVIDER       MODULE      FUNCTION                      NAME
  129 mozilla3516         libxul.so          mozdtrace_load_uri_start   
load-uri-start

We are wrapping the C++ probes in extern "C" funcs simply to avoid 
leaking these Unstable interfaces, which just seems broken to me. Or to 
be technical, this really sucks ;)
In addition I also need to put the <PROBE>_ENABLED macro into this 
wrapper function or it will also bleed into the probe namespace as shown 
by dtrace -l :( By having to do so I will always pay the cost of a func 
call for these probes, which really sucks. Even though if the probe is 
not enabled the func body will do nothing. No big deal for some high 
level funcs, but put the probe in a lower level lib call that's getting 
hit 1000's of times a sec and even an empty func call can hurt.

What do folks think?

JR