dtrace discuss - Nov 2007 - how can I list probes available in an executable?

It seems, that despite marketting claims, in Leopard the Perl executable (in
/usr/bin/perl) comes without probes. If I knew how to list probes in an
executable I could verify my claim.
New to dtrace, I may not see the obvious.


--
This message posted from opensolaris.org

Looks like Leopard perl executable does have perl probes but they are
different from the once listed in
http://blogs.sun.com/alanbur/entry/dtrace_and_perl

Here is what I did.

On one terminal ran perl and on another ran

$ ps -ef | grep perl
   501  4385  4373   0   0:00.01 ttys000    0:00.01 perl

$ sudo dtrace -l -n perl4385:::
    ID   PROVIDER            MODULE                          FUNCTION  
NAME
18659   perl4385     libperl.dylib                      Perl_pp_sort  
entry
18660   perl4385     libperl.dylib                   Perl_pp_dbstate  
entry
18661   perl4385     libperl.dylib                  Perl_pp_entersub  
entry
18662   perl4385     libperl.dylib                      Perl_pp_last  
exit
18663   perl4385     libperl.dylib                    Perl_pp_return  
exit
18664   perl4385     libperl.dylib                     Perl_dounwind  
exit
18665   perl4385     libperl.dylib                Perl_pp_leavesublv  
exit
18666   perl4385     libperl.dylib                  Perl_pp_leavesub  
exit

Alan''s blog talks about sub-entry and sub-return probes which do not
exist in Leopards version of the probes.

May be the apple folks can clarify.

-Angelo


On Nov 27, 2007, at 11:28 AM, St?phane Payrard wrote:
> It seems, that despite marketting claims, in Leopard the Perl  
> executable (in /usr/bin/perl) comes without probes. If I knew how to  
> list probes in an executable I could verify my claim.
> New to dtrace, I may not see the obvious.
>
>
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

On Tue, Nov 27, 2007 at 11:51:05AM -0500, Angelo Rajadurai
wrote:
> Looks like Leopard perl executable does have perl probes but they are
> different from the once listed in
http://blogs.sun.com/alanbur/entry/dtrace_and_perl
> 
> Here is what I did.
> 
> On one terminal ran perl and on another ran
> 
> $ ps -ef | grep perl
>    501  4385  4373   0   0:00.01 ttys000    0:00.01 perl
> 
> $ sudo dtrace -l -n perl4385:::
>     ID   PROVIDER            MODULE                          FUNCTION  
> NAME
> 18659   perl4385     libperl.dylib                      Perl_pp_sort  
> entry
> 18660   perl4385     libperl.dylib                   Perl_pp_dbstate  
> entry
> 18661   perl4385     libperl.dylib                  Perl_pp_entersub  
> entry
> 18662   perl4385     libperl.dylib                      Perl_pp_last  
> exit
> 18663   perl4385     libperl.dylib                    Perl_pp_return  
> exit
> 18664   perl4385     libperl.dylib                     Perl_dounwind  
> exit
> 18665   perl4385     libperl.dylib                Perl_pp_leavesublv  
> exit
> 18666   perl4385     libperl.dylib                  Perl_pp_leavesub  
> exit
> 
> Alan''s blog talks about sub-entry and sub-return probes which do
not
> exist in Leopards version of the probes.
We''re not sure why the entry probes are named "entry"
(instead of "sub-entry",
which is much truer to both DTrace and Perl) and -- more gallingly -- why
the return probes are named "exit".  (DTrace historians will recall
that
this particular issue was one of considerable deliberation, with a vestigal
version of the syscall provider -- nee "systrace" -- having
"exit" instead
of "return" probes from its introduction in d10_16 through to its
rechristening in d10_18.  But I digress...)
> May be the apple folks can clarify.
We have an open question to Apple on this issue.  James agreed that it
was odd, and is following up with the responsible engineer.  James, 
perhaps you could send your findings to dtrace-discuss?

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks.       http://blogs.sun.com/bmc

On Nov 27, 2007, at 8:28 AM, St?phane Payrard wrote:
> It seems, that despite marketting claims, in Leopard the Perl  
> executable (in /usr/bin/perl) comes without probes.
The "marketting claims" [sic] are based on technical information I  
provided. That information is correct as it stands.
> If I knew how to list probes in an executable I could verify my claim.
il0102b-dhcp85:perl-51 luser$ perl &
[1] 15515
il0102b-dhcp85:perl-51 luser$ sudo dtrace -l | grep perl
21600  perl15515     libperl.dylib                      Perl_pp_sort  
entry
21601  perl15515     libperl.dylib                   Perl_pp_dbstate  
entry
21602  perl15515     libperl.dylib                  Perl_pp_entersub  
entry
21603  perl15515     libperl.dylib                      Perl_pp_last  
exit
21604  perl15515     libperl.dylib                    Perl_pp_return  
exit
21605  perl15515     libperl.dylib                     Perl_dounwind  
exit
21606  perl15515     libperl.dylib                Perl_pp_leavesublv  
exit
21607  perl15515     libperl.dylib                  Perl_pp_leavesub  
exit
>
> New to dtrace, I may not see the obvious.
In which case, it might have been wiser not to impugn our "claims" .  
Look before you leap ...

SCP
--
Steve Peters
scp at mac.com

>
> We have an open question to Apple on this issue.  James agreed that it
> was odd, and is following up with the responsible engineer.  James,
> perhaps you could send your findings to dtrace-discuss?
	I''ve talked with the folks involved, I think this was just an
accident.

	It does raise an interesting point, though. How does one deprecate
an existing probe naming?

	I tried making a provider with stability level "Obsolete" for names,
but I didn''t get any warnings when using the resulting probes. Assuming
we could get warnings for Obsolete names, how does one mark only
portions of a provider as deprecated? I.E.:

provider SomeProbesAreObsoleteButNotAll {
	probe entry(); // This needs to be deprecated
	probe sub-entry(); // This is the new name
};

	James M

On Tue, Nov 27, 2007 at 12:41:23PM -0800, James McIlree
wrote:
> >
> > We have an open question to Apple on this issue.  James agreed that it
> > was odd, and is following up with the responsible engineer.  James,
> > perhaps you could send your findings to dtrace-discuss?
> 
> 	I''ve talked with the folks involved, I think this was just an
accident.
> 
> 	It does raise an interesting point, though. How does one deprecate
> an existing probe naming?
> 
> 	I tried making a provider with stability level "Obsolete" for
names,
> but I didn''t get any warnings when using the resulting probes.
Assuming
> we could get warnings for Obsolete names, how does one mark only
> portions of a provider as deprecated? I.E.:
> 
> provider SomeProbesAreObsoleteButNotAll {
> 	probe entry(); // This needs to be deprecated
> 	probe sub-entry(); // This is the new name
> };
> 
> 	James M
We don''t permit stability attributes to be set per-probe, only
per-provider.
(We felt originally this incurred too much additional space overhead per
probe with limited benefit).  Personally given the nature of this issue 
I would just change it, since it''s simply a bug.

-Mike

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

>
> We have an open question to Apple on this issue.  James agreed that it
> was odd, and is following up with the responsible engineer.  James,
> perhaps you could send your findings to dtrace-discuss?
>
> 	- Bryan
	Just to verify...

	These are the recommended signatures for perl/python, correct?

provider perl {
         probe sub__entry(char*, char*, int);
         probe sub__return(char*, char*, int);
};

provider python {
	probe function__entry(const char *, const char *, int);
	probe function__return(const char *, const char *, int);
};

	James M

Hey James,

On Tue, Nov 27, 2007 at 06:53:32PM -0800, James McIlree
wrote:
> >
> > We have an open question to Apple on this issue.  James agreed that it
> > was odd, and is following up with the responsible engineer.  James,
> > perhaps you could send your findings to dtrace-discuss?
> >
> > 	- Bryan
> 
> 	Just to verify...
> 
> 	These are the recommended signatures for perl/python, correct?
> 
> provider perl {
>          probe sub__entry(char*, char*, int);
>          probe sub__return(char*, char*, int);
> };
> 
> provider python {
> 	probe function__entry(const char *, const char *, int);
> 	probe function__return(const char *, const char *, int);
> };
Yep -- those are the ones...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks.       http://blogs.sun.com/bmc

> The "marketting claims" [sic] are based on technical information
I
> provided. That information is correct as it stands.
Thx. Sorry for the word "claim", I meant "hypothesis".  
Perhaps also some tutorial documentation on how Apple dtrace differs from
Solaris one (or a pointer to the difference doc) would be great. It seems Apple
one misses a -G option and added an -arch one.

Thx for a great tool and a timeful and helpful support.
> Look before you leap ...
I was stuck. By looking this forum i can leap :)


--
This message posted from opensolaris.org