[Development] Tracing Qt

[André Pönitz]

On Fri, Aug 23, 2013 at 12:30:09PM +0000, Rutledge Shawn wrote:
> 
> On 23 Aug 2013, at 1:20 PM, Robin Burchell wrote:
> > Thoughts, flames, cookies?
> 
> Yes I've been interested in doing something like that too, for debugging
> touch and other types of events.  The biggest problem with events is that
> they get converted into different types and queued multiple times, which
> is both inefficient and hard to debug.  My goal is to be able to trace an
> OS touch event all the way through to the QtQuick item which handles the
> QtQuick-specific form of the event.  So I think this is (yet another?)
> high-priority thing to get done; and I don't think it's hard, we just
> need to agree whether it's OK to "clutter" the code with these trace
> lines.  And to avoid performance impact we need to be sure that in
> non-debug builds, the code disappears completely.  I think that means the
> trace lines should use a macro, so that the macro can be #defined to a
> no-op for non-debug builds.  The trace lines should be one-liners so we
> don't have #ifdef/endif clutter around all of them, but they should
> generate no machine code whatsoever when Qt is compiled in no n-debug
> mode.  Otherwise it would become hopeless to use it in
> performance-critical code.

To my understanding so far it is an explicit goal to be able to
use the tracers also in release builds, also within performance
critical code.

> As an example, if you want a DEBUG macro which expands to printf, you
> will need a varargs version of the macro to use when you want to compile
> without debug support.  e.g.  #define DEBUG(format, args...) ((void)0)
> And varargs macros are not supported by all compilers.  But a macro which
> takes a fixed number of args is easy to turn into a no-op.
> 
> There are alternatives.  One could write a script or some other type of
> tool which can insert the trace lines into your source tree whenever you
> want to do some tracing, so that the source code clutter is there only
> when you want it.

I don't think we are talking about the same thing right now.

> [...]
> Tracing certain function entry/exit points would also be enough some of
> the time for some use cases, but not all the time (e.g. when we are only
> interested in certain branches of a switch). 

The idea is to be flexible on what parts are traced, and what the tracer
can do. It is understood that for quite a couple of cases there are
solutions, either the ad-hoc bits that are in the code already, or by
using external tools.

> If it were enough, then it would be possible to write something like a
> debugger which automatically creates a gazillion breakpoints, and each
> time it hits one, it logs the fact and automatically continues. 

This fails to meet the performance constraints. Assuming we are talking
about something like gdb, Hitting a "normal" breakpoint and deciding to
continue takes several milliseconds as minimum. The proposed solution here
is a stack guard object checking a global flag first, i.e. a handful of
instructions in the no-trace case. There are a few orders of magnitude on
performance impact between these two approaches.

> Then the Qt source wouldn't require
> modifications, only the same debug symbols that gdb etc. already use.
> This sort of thing has been done before too (but I'd have to google again
> to find those projects again).

Maybe you are thinking of http://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
which addresses at least the performance problem. It is, however, pretty
limited in what kind of operation it can (easily) trigger, and need quite
a bit of handholding to set up.

> If the trace clutter bothers people, they could be kept in separate
> patches which are maintained so that they can always be applied
> on-demand.  But then the danger is code rot in those patches.  It would
> be less trouble if the patch tool was more intelligent, based on
> recognizing similar-looking code instead of a line-by-line diff.  But
> then it's more like a script to add the traces rather than just a patch.

Are you sure we are already discussing real problems or are we inventing
some? I don't think _one line_ per "interesting" function will turn out
to be a problem justifying extra build steps
 
> Either way it would tend to need autotests to keep it working.
> 
> Whatever we do might benefit from sharing some of the QDebug/QWarning
> related code instead of starting over from scratch.  And those are not as
> flexible as they could be, either.  At one previous commercial job we had
> a custom log function which underneath was QDebug with a category field
> added to each line, and then there was a GUI window for viewing and
> filtering the debugs in real-time as the software emitted them.  That
> sort of thing could be built in to Qt, too.  At some point tracing and
> logging could be essentially the same thing, if we design it that way.

Right, but I doubt that's easy to do that under the usual compatibility
constraints. 
 
> So it's kindof a tricky problem, but I hope we can at least agree on some
> useful framework for the near term.

Maybe the way to go is to simply create a patch and discuss that on
gerrit then. 

Andre'