[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
csdavec at swan.ac.uk
Mon Apr 9 11:08:08 PDT 2012
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.
More information about the cfe-dev