Analyzing code path in Objective C a la TraceGL?

Question

TraceGL is a pretty neat project that allows JS programmers to trace code paths in Javascript. It looks something like this:

I'd like to build something similar for Objective C. I know the runtime has made it rather easy to trace method calls, but how would I trace control flow? For example, in the screenshot above, code paths not executed are made obvious with a red highlight. What would be the best way to achieve something similar in an Objective C/Xcode workflow?

The best I've come up with so far is to write a preprocessor that injects code into temporary source files before sending them to the compiler. Anyone have a better idea?

Answer 1

I guess the visualizer for issues found by Xcode's static analyzer comes pretty close to this - albeit this one will only give you the call path for a particular issue like a memory leak.

Try "Product > Analyze" in Xcode, select any of the issues found on any given project and click on the blue arrow in the code editor to see for yourself.

Answer 2

Not exactly answer for Objective C and XCode.

For C++ code there is a industrial quality code coverage tool BullseyeCoverage

• Function coverage gives you a quick overview and condition/decision coverage gives you high precision
• Works with everything you can write in C++ and C, including system-level and kernel mode

If you want to invent/write this kind of tool yourself I'd recommend to take a look at (evaluate) some existing tools that solve the same task so that you don't miss a key functionality

There are basically 2 categories of such tools

• working at binary level, instrument byte code, library entry points etc.
• working at source level, instrument source code before going to the compiler

The purpose of the instrumentation is to insert into the code calls to a profiling runtime that collects the runtime statistics for further processing.

Basic calls

• timestamp, thread id, source code address, entering
• timestamp, thread id, source code address, leaving

The source code address depends on the granularity you are interesetd in. It can be a function name ot it can be a source file and line number.

Collected performance data can be quite huge so they are usually summed-up and whole callstacks are not captured. It is usually sufficient level of detail for detecting performance bottlenecks.

Another drawback is that capturing detailed performance data especially in code points with many hits will slow the application significantly.

If you want complete history then capture the full trace including timestamps and thread-ids and you will be able to recreate the call stacks later knowing that each enter has corresponding leave.

To guarantee this pairing the code instrumentation must insert exception handling calls to make sure that exit point will be logged even if the function throws an exception (what is the "exception" and how to try-finally it dependes on the language and the OS platform).

To get all necessary tricks and tips evaluate some tools and take a look at their instrumentation style.

BTW: in general it is quite a lot of work to do and to get right I'd personally thought twice or more times about what will be the outcome and what will be the costs.

As a want-to-play-with topic I fully recommend that. I created such a tool for troubleshooting Java MIDP applications working at C++ source level and Java binary level and it was helpful at the time when we needed it.