[Development] new "debugsupport" module and API

André Pönitz apoenitz at t-online.de
Wed May 14 23:20:10 CEST 2014

On Wed, May 14, 2014 at 11:37:45AM +0200, Milian Wolff wrote:
> On Tuesday 13 May 2014 21:58:29 André Pönitz wrote:
> > On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote:
> > > > Please create a new module. This doesn't need to be in qtbase.
> > > 
> > > Is anyone opposed to keeping this in a separate qtdebugsupport.git
> > > repository, then?
> > 
> > I am.
> > 
> > At the very least, this is still missing an explanation what actual
> > problems this is going to solve, and a few _plausible_ scenarios
> > where this code will be reused.
> >
> > A couple of users actually asking for such a framework would already
> > help to understand the need.
> Hey Andre,
> let me (re-)raise two valid use cases for this new repository: GammaRay and 
> KDevelop (as previously mentioned by Kai). But I guess people out there 
> working on any other IDE might want to use it eventually, if they add support 
> for QML. Momentics comes into mind there.

> > Once the need to have it is established, the implementation can be
> > discussed.
> I would like to see such a debugsupport module.

That's a clear vote.

I'd still like to try to set expectations right:

I understand the proposition _sounds_ good, and the code actually _looks_
good. But it doesn't _do_ anything sensible, nor does it help when
trying to do anything sensible.

What's currently proposed to be moved into Qt Base is several thousand
lines of pure "infrastructure" for things like packet and connection

_There is no actual debugging or profiling service included_.

The communication protocol used is completely ad-hoc, and not used by
anything else in the world.

This infrastructure supports _only_ services that run _inside_ the
application it examines, i.e. a "profiler" based on this framework shares
address space, including heap, network connection etc. with the object it
claims to profile, _while using resources of this object for its own

Unless special measure are taken, the service will remain and be accessible
in the deployed application. There is no build-in security.

This infastructure cannot be used to interface classical profiling/debugging
tools like Valgrind, GDB, etc.

It does _not_ simplify IDE integration:

First, it can as-is only be used with Qt based clients/IDEs. This won't
be much of a problem for KDevelop or GammaRay, but e.g. Momentics would
have to wrap or essentially re-do the client side in Java.

Second, Qt based frontends do not get a free ride either. Exemplified by
Qt Creator: The amount of code needed to use that framework in the debugger
plugin to make QML debugging work is in the same order as the amount of
code we have for the "direct" GDB and LLDB interfaces. And to put it into
proportion, plugin/debugger/qml/* is roughly 1.5 the size plugins/designer,
the Qt Designer integration.

I maintain that this framework is completely over-engineered. It does not
work like typical tools in the field, nor does it help to write such tools.
I believe there is not a single use case where it gives any benefit over a
direct implementation of whatever kind of communication/data extraction is
needed. This code does not belong into Qt Base, nor should it be advertised
as a re-usable framework.


More information about the Development mailing list