On Mar 26, 2008, at 9:58 AM, Sudheer wrote:
> Hi,
> I am using DTrace to analyze Mozilla Firefox. I want to print
> the ustack, args[2] for the following two C++ methods.
> --------------------
> nsComponentManagerImpl::CreateInstance(const nsCID &aClass,
> nsISupports *aDelegate,
> const nsIID &aIID,
> void **aResult)
>
> nsComponentManagerImpl::CreateInstanceByContractID(const char
> *aContractID,
> nsISupports
> *aDelegate,
> const nsIID &aIID,
> void **aResult)
>
> struct nsID {
> /**
> * @name Identifier values
> */
>
> //@{
> PRUint32 m0;
> PRUint16 m1;
> PRUint16 m2;
> PRUint8 m3[8];
> //@}
> .....
>
> typedef nsID nsIID;
>
> -------------------
> So, I wrote the probes as follows.
>
> -------------------
> pid
> $
> target:XUL
> :__ZN22nsComponentManagerImpl26CreateInstanceByContractIDEPKcP11nsISupportsRK4nsIDPPv:entry
> {
> printf ("iid : %08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
> args[2].m0, args[2].m1, args[2].m2, args[2].m3[0], args[2].m3[1],
> args[2].m3[2], args[2].m3[3], args[2].m3[4], args[2].m3[5],
> args[2].m3[6], args[2].m3[7]);
> ustack ();
> }
>
> pid
> $
> target:XUL
> :__ZN22nsComponentManagerImpl26CreateInstanceByContractIDEPKcP11nsISupportsRK4nsIDPPv:entry
> {
> printf ("iid : %08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
> args[2].m0, args[2].m1, args[2].m2, args[2].m3[0], args[2].m3[1],
> args[2].m3[2], args[2].m3[3], args[2].m3[4], args[2].m3[5],
> args[2].m3[6], args[2].m3[7]);
> ustack ();
> }
> ~-------------------
> I used nm (otool) to get these mangled names.
>
> DTrace complains that these does not match any probes.
OS X's default is to use demangled names. If you add -xmangled, you
should be able to match on the mangled names:
ghopper:/BuildResults/Debug# dtrace -l -n
'pid71808::__ZN10__cxxabiv119__pointer_type_infoD2Ev:entry'
ID PROVIDER MODULE FUNCTION
NAME
dtrace: failed to match
pid71808::__ZN10__cxxabiv119__pointer_type_infoD2Ev:entry: No probe
matches description
ghopper:/BuildResults/Debug# dtrace -l -xmangled -n
'pid71808::__ZN10__cxxabiv119__pointer_type_infoD2Ev:entry'
ID PROVIDER MODULE FUNCTION
NAME
19029 pid71808 libstdc++.6.dylib
__ZN10__cxxabiv119__pointer_type_infoD2Ev
[__cxxabiv1::__pointer_type_info::~__pointer_type_info()] entry
19030 pid71808 dyld
__ZN10__cxxabiv119__pointer_type_infoD2Ev
[__cxxabiv1::__pointer_type_info::~__pointer_type_info()] entry
>
>
> So, I changed the probes to *nsComponentManagerImpl*CreateInstance[!
> B]* and *nsComponentManagerImpl*CreateInstanceByContractID*
>
> Now DTrace complains
>
> dtrace: failed to compile script /Users/sudheer/work/prof/dtrace/
> compssrvcs.d: line 7: args[ ] may not be referenced because probe
> description pid181::*nsComponentManagerImpl*CreateInstance[!
> B]*:entry matches an unstable set of probes
The args[] array doesn't work with the pid provider, you'll need to
use arg0, arg1, etc.
>
>
> I tried dtrace -l -p <pid of firefox> | grep -i createinstance and I
> got no output.
This isn't doing what you think it is. Pid probes are created on
demand, and that isn't
demanding any :-). Its not what you want even if it did, as a wildcard
will attempt to create all
probes, including offset probes. In other words, "make a probe for
every instruction in Firefox".
Its pretty unlikely you'd be able to create enough probes before
hitting some kind of memory
limit.
> So, I commented using args[2] but just did ustack(). In that case,
> DTrace output contained only two probeIDs (and two CPU IDs, if that
> matters). Also, the probe IDs differ each time I run the program.
Each pid gets its own set of probes. A different pid means different
probe ids.
> - How can I fix this?
> - Why dtrace -l is not listing these functions? but can produces
> output with probeIDs?
> - Is there a way to use these probe IDs in the D script?
Yes, but you don't want to.
> - Why the probe IDs differ? Is it something to do with shared
> libraries?
> - Is there a way for me to get the output I want by using arg2?
> instead of args[2]
argX is "mostly" the same as args[X]. The difference is that argX is
the raw
ABI, not a typed argument. So you'll run into things like "On this
arch, a 64 bit value
is passed in two argument slots." If you don't get the answers you
expect, you're probably
going to need to dig into the ABI to figure out where the data you
want is stored.
Just in case, here is the document you should hope you don't have to
read :-)
http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Introduction.html
James M
_______________________________________________
dtrace-discuss mailing list
[email protected]
