[cfe-dev] Fwd: [cfe-commits] r154321 - in /cfe/trunk: include/clang/Driver/CC1Options.td include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.h lib/CodeGen/CGObjCGNU.cpp lib/Driver/Tools.cpp lib/Frontend/CompilerInvocation.cpp test/CodeGenObjC/trace.m

[David Chisnall]

On 9 Apr 2012, at 18:43, Jordan Rose wrote:

> It seems like this is unnecessary. Why not just provide a custom libobjc, interpose objc_msgSend, or such? 
> I suppose this way you only get logs from /your/ code and not framework code...

You're answering your own question.  Producing visualisations of a subset of the program is useful.  The performance hit from tracing everything can affect the semantics of complex code, so turning it on and off at a finer granularity than per-process is useful.  It's also useful for the usability of the resulting visualisations if you only want to see how a few classes interact.

> (Also see http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/ -- there are a couple ways to trace ObjC messages /already/ in Apple's runtime...circa 2006, i.e. GNU runtime. Presumably these can be extended to non-Apple platforms as well.)

The Apple runtime is not the GNU runtime, the two implement different ABIs.  

David