An simple idea for DTrace and Xcode integration
An simple idea for DTrace and Xcode integration
- Subject: An simple idea for DTrace and Xcode integration
- From: "John Engelhart" <email@hidden>
- Date: Sat, 24 Nov 2007 05:48:29 -0500
I'm deep in the middle of adding user defined dtrace probe points, and
in one of those flashes of inspiration, the following idea popped in
to my head:
The idea combines two things: The new "bubble messages" in Xcode 3.0,
and DTrace. The details that follow are more to illustrate the point
rather than suggest the architecture for the final solution.
In simple terms, a "well known" dtrace probe point is defined with a
handful of arguments. For the sake of argument, we'll set the
argument parameters to "int level" and "char *utf8CStringMessage".
Level is roughly along the lines of "debug / notice / warning / error"
variety, and the message parameter should be obvious.
Then, for simplicity, we have a function (or cpp macro wrapper, etc)
called NSDebug() which for all practical concerns behaves exactly like
NSLog().
Now, the subtle difference is that when you 'Run' your application
from Xcode, Xcode will enable the previously well known probe point in
the launched executable. When NSDebug is called, it prints a message
just as NSLog() would have, but also fires the dtrace probe with a
pointer to that message. Xcode would copy the message and a stack
trace with ustack(). Then, for all the stack frames that Xcode can
match up to source code, it would append a Xcode bubble item of the
message to the corresponding line.
Ever get a message along the lines of "Set a break point at xxx to
catch"? If such a message was sent through the proposed NSDebug(),
the lines in your source (assuming there's debug symbols, of course)
that caused the message would immediately be highlighted with the
offending message. Think about how many bugs can be solved just by
having an idea of where the problem happened. The great thing is that
these would be available all the time, automatically, from any
application launched by Xcode (or possibly even 'attached to'). No
having to restart under the debugger and wait for the problem to
happen again, you'd have everything you needed right there. And in
your own code, think how useful it would be to have NSLog() messages
that could automatically be correlated to all the relevant lines of
code in the stack trace.
Along the same lines, imagine if the Objective-C exception handling
framework was hooked in to via dtrace by Xcode. Then, when an
uncaught exception has bubbled up, Xcode could capture this event and
the stack trace that caused it and for stack frames that it can
correlate to open source files, populate the corresponding lines with
the exception details in a bubble. While I don't know the specifics,
it wouldn't surprise me if this would be a trivial dtrace probe point
and predicate rule to gather all the relevant information, including
stack trace, with zero modifications to any system libraries or code.
Hell, I bet the Xcode team could have a proof of concept up in running
in a few hours.
Just imagine how useful this would be the next time a NSArray
NSRangeException scrolls by. With this feature, the lines of code
that caused it would automatically get tagged with the message, even
if you didn't launch your app under the debugger.
I know that for me, this one simple addition to Xcode would save hours
and hours of time. And it's easy to get carried away with it, such as
having "smart NSLog() statements". Those "set a debugger to xxxx to
catch" messages? A flag set in one of the arguments of the dtrace
probe could indicate "drop to debugger if possible", which should be
down right trivial with dtrace (the dtrace action would call stop(),
and once xcode sees the message, it would know to spin gdb up and
attach it to the halted process)
Thoughts from the community? A 'must have' feature for Xcode 3.1?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden