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' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
