Re: DTrace Questions
Re: DTrace Questions
- Subject: Re: DTrace Questions
- From: Eric Gorr <email@hidden>
- Date: Sun, 9 May 2010 19:06:59 -0400
On May 8, 2010, at 5:55 PM, Eric Gorr wrote:
> While this is certainly true, it does not apply to this case.
>
> I created a test application which you can find at http://ericgorr.net/cocoadev/dtracetest.zip.
>
> If you run the release build and then execute
>
> sudo dtrace -l -n 'pid40333:dtracetest::entry'
>
> The result will be:
>
> ~ $sudo dtrace -l -n 'pid40333:dtracetest::entry'
> Password:
> ID PROVIDER MODULE FUNCTION NAME
> dtrace: failed to match pid40333:dtracetest::entry: No probe matches description
>
> i.e. No entry probes are found...not even for my Objective-C methods.
>
> nm reports:
>
> ~ $nm /Users/ericgorr/Desktop/dtracetest/build/Release/dtracetest.app/Contents/MacOS/dtracetest
> U _NSApplicationMain
> U _OBJC_CLASS_$_NSObject
> U _OBJC_METACLASS_$_NSObject
> 0000000100000000 A __mh_execute_header
> U __objc_empty_cache
> U __objc_empty_vtable
> U _exit
> U _objc_msgSend
> U dyld_stub_binder
>
> Now, perhaps, if I changed the provider or something to be the objective-c one, it would list my objective-c methods, but I am uncertain how to verify that. If you happen to know, I would be interested in learning about it.
>
> The reason why I was getting probes back on a Release build before is because dtrace uses spotlight to search for dSym's for your application and can use the dSym file to automatically generate entry and return probes. You can easily verify this by building the project and generating the dSym file. dtrace -l will report back entry and return probes (among some others) now. And, of course, trashing the dSym file will return it back to the state where the probes can no longer be found. One can, of course, place the dSym file in a folder that won't be indexed by Spotlight to prevent dtrace from locating it. Interesting stuff and no longer surprises me now that I understand what is happening. :-)
>
> Of course, if you run the debug build, where all of the symbols haven't been stripped from it, you will get the expected:
>
> ~ $sudo dtrace -l -n 'pid42589:dtracetest::entry'
> Password:
> ID PROVIDER MODULE FUNCTION NAME
> 24376 pid42589 dtracetest start entry
> 24377 pid42589 dtracetest main entry
> 24378 pid42589 dtracetest -[dtracetestAppDelegate myMethod:] entry
> 24379 pid42589 dtracetest -[dtracetestAppDelegate applicationDidFinishLaunching:] entry
> 24380 pid42589 dtracetest -[dtracetestAppDelegate buttonPushed:] entry
> 24381 pid42589 dtracetest -[dtracetestAppDelegate window] entry
> 24382 pid42589 dtracetest -[dtracetestAppDelegate setWindow:] entry
> 24383 pid42589 dtracetest max entry
> 24384 pid42589 dtracetest myCFunc entry
> 24385 pid42589 dtracetest stub helpers entry
>
> This brings up an interesting question. Does the automatic generation of these entry & return probes affect a running application in anyway? To be more specific, is code being inserted into the application or executed somewhere else to check, for example, if the myCFunc entry probe is enabled or not every time myCFunc is executed?
>
> I would assume that the answer is NO to both questions. Extra code would only be inserted or executed if dtrace was told to enable the probe (by Instruments, for example). Is this correct?
If anyone is interested, I have learned that the answer to this question is YES.
So, this brings up another question:
Is it possible to supply a file (an alternative dSym or some other kind of file) which dtrace will use to generate entry & return probes for only a small subset of functions? If so, how would one generate and use this file?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden