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.
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
I tried dtrace -l -p <pid of firefox> | grep -i createinstance and I got
no output.
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.
- 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?
- 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]
I will really appreciate your help.
--
This message posted from opensolaris.org
BTW, I am using DTrace on Mac - Leopard. -- This message posted from opensolaris.org
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 probesThe 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
> OS X''s default is to use demangled names. If you add > d -xmangled, you > should be able to match on the mangled names: >Thanks a lot James. With -xmangled, the function is recognized. But I ran into a new problem, where dtrace says index 2 is out of range for args []!> The args[] array doesn''t work with the pid provider, > , you''ll need to > use arg0, arg1, etc.Hmm.. DTrace is complaining that 2 is out of range for args[]. arg2 is 64 bit address and it does not have type. So, I can''t do things like arg2.m1, etc..> This isn''t doing what you think it is. Pid probes > s 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 > h probes before > hitting some kind of memory > limit.This was working and it gave me output (like ustack). Only thing was it did not allow me to use args[]> > Each pid gets its own set of probes. A different pid > d means different > probe ids.Makes sense. :-)> argX is "mostly" the same as args[X]. The difference > e 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 > e you don''t have to > read :-) > > http://developer.apple.com/documentation/DeveloperToo > ls/Conceptual/LowLevelABI/Introduction.html > > James MIs there no easier way? :-( As the third argument is a const reference to an object, how can I use arg2 to get what I wanted? Can I do tracemem ( copyin (arg2, 32), 32)? -- This message posted from opensolaris.org
On Mar 26, 2008, at 1:59 PM, Sudheer wrote:> >> argX is "mostly" the same as args[X]. The difference >> e 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 >> e you don''t have to >> read :-) >> >> http://developer.apple.com/documentation/DeveloperToo >> ls/Conceptual/LowLevelABI/Introduction.html >> >> James M > > Is there no easier way? :-( > As the third argument is a const reference to an object, how can I > use arg2 to get what I wanted? > > Can I do tracemem ( copyin (arg2, 32), 32)?Unfortunately, there isn''t an easier way for pid arguments (yet). Without knowing the exact details of what you are trying to do, I can''t say for certain which arg register to use. A simple first try on 32 bit x86 is one arg for the "this" pointer, and then just count arguments. If anything is 64 bit, it will take two argument slots. Anything fancy and you''ll have to take a look at the ABI document to see how it is passed. James M