Track all ObjC method calls?

Question

Sometimes when looking at someone else's large Objective-C program, it is hard to know where to begin.

In such situations, I think it would be helpful to log every call to every non-Apple method.

Is there a way to do that? Basically, make one change in some central place, and log every method that is called. Preferably limited to non-Apple methods.

Answer 1

You can set the environment variable NSObjCMessageLoggingEnabled to YES. This will write a log of all message sends in the folder /tmp/msgSends-xxx.

Answer 2

You could add a symbolic breakpoint to objc_msgSend(), and have it log the second parameter without stopping.

How to do it for your own methods only though is a toucher task. Maybe if you could inspect the class name being called and do some magic to have a conditional breakpoint for only calls where the class' prefix matches your own?

Answer 3

I don't think logging every single call is practical enough to be useful, but here's a suggestion in that direction.

On a side note, if it's a large program, it better have some kind of documentation or an intro comment for people to get started with the code.

In any case, every Cocoa application has an applicationDidFinishLaunching... method. It's a good place to start from. Some apps also have their principal (or 'main window') class defined in the Info.plist file. Both these things might give you a hint as to what classes (specifically, view controllers) are the most prominent ones and what methods are likely to have long stack-traces while the program is running. Like a game-loop in a game engine, or some other frequently called method. By placing a breakpoint inside such a method and looking at the stack-trace in the debugger, you can get a general idea of what's going on.

If it's a UI-heavy app, looking at its NIB files and classes used in them may also help identify parts of app's functionality you might be looking for.

Another option is to fire up the Time Profiler instrument and check both Hide missing symbols and Hide system libraries checkboxes. This will give you not only a bird's eye view on the methods being called inside the program, but also will pin-point the most often called ones.

By interacting with your program with the Time Profiler recording on, you could also identify different parts of the program's functionality and correlate them with your actions pretty easily.