Re: How to get an overview of class interactions, call-graphs, process analysis etc.?
Re: How to get an overview of class interactions, call-graphs, process analysis etc.?
- Subject: Re: How to get an overview of class interactions, call-graphs, process analysis etc.?
- From: Ken Thomases <email@hidden>
- Date: Sun, 5 Oct 2008 10:57:18 -0500
On Oct 5, 2008, at 5:37 AM, Riehm Stephen wrote:
Does anyone here have some tips for getting this kind of code
analysis graphically with XCode, gdb, dtrace and Co.?
DTrace can be used for this, with some caveats. Apple has extended
DTrace with an "objc" provider. Here's an example one-liner:
sudo dtrace -F -n 'objc$target:MyClass*::entry, objc
$target:MyClass*::return {}' -c /path/to/MyApp.app/Contents/MacOS/MyApp
This asks DTrace to run MyApp and trace the entry and return of every
method in classes matching the pattern MyClass*. The asterisk is a
wildcard, allowing this to match categories on MyClass (as well as,
for example, MyClass2). If all of your classes start with a common
prefix, you can use that prefix and an asterisk to trace the methods
of all of your classes. If you have more classes you want to trace
and they don't have a common prefix, you can just keep listing probe
points separated by commas.
The -F switch asks DTrace to format its output as a call tree.
One caveat of this is that DTrace output from each CPU (or core) is
independent. If your process migrates from one CPU to another, then
DTrace can get data out of order. It also doesn't realize that a
method entry on one CPU is matched to a return on another CPU.
You can work around this problem, but it's sort of a pain. The basic
technique is to drop the -F switch, have your probe actions print raw
data about method entry, return, thread ID, and per-thread sequence
number. Then, you post-process the output to build the call tree.
The attached script demonstrates this technique. You have to invoke
it with the -C switch to invoke the C preprocessor on the script. It
outputs tab-delimited data which you can process in something like
Numbers or Excel (or a variety of other tools). Sorting by the thread
ID and then the per-thread sequence compensates for the out-of-order
problem. The "level" column corresponds to the indent level of -F
output.
I don't know if Instruments addresses this issue when you build a
custom DTrace instrument.
Cheers,
Ken
Attachment:
manual_call_tree.d
Description: Binary data
_______________________________________________
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