6

Assume I have a Cocoa-based Mac or iOS app. I'd like to run a static analyzer on my app's source code or my app's binary to retrieve a list of all Objective-C methods called therein. Is there a tool that can do this?

A few points:

  1. I am looking for a static solution. I am not looking for a dynamic solution.

  2. Something which can be run against either a binary or source code is acceptable.

  3. Ideally the output would just be a massive de-duped list of Objective-C methods like:

    …
-[MyClass foo]
…
+[NSMutableString stringWithCapacity:]
…
-[NSString length]
…
    (If it's not de-duped that's cool)

  4. If other types of symbols (C functions, static vars, etc) are present, that is fine.

  5. I'm familiar with class-dump, but AFAIK, it dumps the declared Classes in your binary, not the called methods in your binary. That's not what I'm looking for. If I am wrong, and you can do this with class-dump, please correct me.

  6. I'm not entirely sure this is feasible. So if it's not, that's a good answer too. :)

Community
  • 1
  • 1
Todd Ditchendorf
  • 11,217
  • 14
  • 69
  • 123

4 Answers4

10

The closest I'm aware of is otx, which is a wrapper around otool and can reconstruct the selectors at objc_msgSend() call sites.

http://otx.osxninja.com/

bbum
  • 162,346
  • 23
  • 271
  • 359
  • 1
    Domain does not exist anymore. http://web.archive.org/web/20130929164302/http://otx.osxninja.com/ from archive dot org. – Klaas Feb 18 '17 at 14:01
7

If you are asking for finding a COMPLETE list of all methods called then this is impossible, both statically and dynamically. The reason is that methods may be called in a variety of ways and even be dynamically and programmatically assembled.

In addition to regular method invocations using the Objective-C messages like [Object message] you can also dispatch messages using the C-API functions from objc/message.h, e.g. objc_msgSend(str, del). Or you can dispatch them using the NSInvocation API or with performSelector:withObject: (and similar methods), see the examples here. The selectors used in all these cases can be static strings or they can even be constructed programmatically from strings, using things like NSSelectorFromString.

To make matters worse Objective-C even supports dynamic message resolution which allows an object to respond to messages that do not correspond to methods at all!

If you are satisfied with only specific method invocations then parsing the source code for the patterns listed above will give you a minimal list of methods that may be called during execution. But the list may be both incomplete (i.e., not contain methods that may be called) as well as overcomplete (i.e., may contain methods that are not called in practice).

Community
  • 1
  • 1
user8472
  • 3,268
  • 3
  • 35
  • 62
  • I like this answer very much. You raise a vitally important point: No static solution can guarantee 100% coverage due to the ObjC runtime/language features you mentioned. I'll let my question stand however, as I think there would still be value in a tool which could find the rest. – Todd Ditchendorf Mar 27 '12 at 17:40
  • 3
    I think bigger than all the metaprogramming weirdness is the problem of not knowing receivers' types at compile time, which is necessary to determine what method is called. When I write `[foo length]`, you don't know if that's `-[NSString length]`, `-[FootballField length]` or `+[SomePoorlyDesignedClass length]` — it might be any combination of the three at runtime, or even some other method loaded from a plugin. So you could determine with pretty high fidelity what *messages* are sent, but it's more iffy trying to say what *methods* are called as a result. – Chuck Mar 27 '12 at 18:31
  • @Chuck Good point. It is not only the selectors, but also the objects themselves that can be constructed dynamically. +1 also for pointing out the subtlety regarding instance and class methods! – user8472 Mar 27 '12 at 18:41
1
otool -oV /path to executable/ | grep name | awk '{print $3}'
applehelpwriter
  • 488
  • 3
  • 8
0

Another great tool is class-dump which was always my first choices for static analysis.

Chris
  • 1,133
  • 7
  • 14