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

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

Hi John,

I wouldn''t get too hung up on what appears in the function field when
listing probes. Users are going to look at your documentation about what
probes to use. Also, if a probe of a given name appears in several functions,
it may be useful to be able to specify just one of those by including the
listed function.

We could do something like not listing components of a probe description
which are less stable than the provider itself or of the other components.
We''d need to give that some careful thought however. Feel free to file
an
RFE.

For the time being, the function name really doesn''t matter, and
shouldn''t
matter to developers.

Adam

On Sat, Sep 01, 2007 at 07:24:54AM -0700, John Rice
wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, FishWorks                        http://blogs.sun.com/ahl