[Development] new "debugsupport" module and API
Thomas.Hartmann at digia.com
Mon May 12 12:13:07 CEST 2014
I guess using a TCP connection would still be possible, but not be the defaut anymore for local debugging/profiling?
From: development-bounces+thomas.hartmann=digia.com at qt-project.org [development-bounces+thomas.hartmann=digia.com at qt-project.org] on behalf of Ulf Hermann [ulf.hermann at digia.com]
Sent: 12 May 2014 11:48
To: development at qt-project.org
Subject: [Development] new "debugsupport" module and API
we currently have several implementations of the QML debug protocol used
to transmit data between a debugger or profiler and the application
being debugged or profiled. I'm proposing a generalized "debugsupport"
module to address various issues with those. In particular:
1. Code duplication
We currently have implementations of QPacketProtocol in:
We have differently named but functionally largely identical
implementations of the qml debug client and connection in:
We also have 2 server implementations, in qtquick1 and qtdeclarative.
The debug clients and servers share a lot of functionality regarding
connection handling and notifying their plugins about various
conditions. Those plugins for servers and clients can share the same
base class as they all expose the same interface to the server or
client. Currently we have 6 of those base classes.
2. Missing flexibility
Currently a TCP connection is used for any kind of debugging or
profiling. This is potentially wasteful and dangerous as TCP has a
certain overhead and the protocol itself doesn't care about security.
Providing a connection over a QLocalSocket at least as an option seems
to be a good idea.
The debug server is currently tied into QtQml, even though it has
technically nothing to do with QML. It's a general purpose tool
for interacting with an application over a defined interface. It should
live in a more appropriate place so that we can use it in other
contexts if the need arises.
3. Messy implementation
Many of the client implementations are badly written, potentially leak
memory, don't properly handle errors, expose too many details of the
underlying connection and provide subtly different interfaces to their
It's also a bad idea to specify the interface between the debug server
and client in terms of an arcane binary protocol full of magic numbers
and with a colorful history (e.g. the protocol version is unusable; we
practically never do service advertisement; in order to extend the
protocol you can only add things to the end of messages, but you can
never change any existing parts; service versions are transmitted as
floats). Hiding the mess behind a clean C++ interface will make it much
easier to work with and enables us to eventually replace the protocol
with something less crazy.
The following changes create a debugsupport module with public API in
I also have some WIP changes for qtdeclarative to use debugsupport:
And for QtCreator:
QtQuick1 will get the same treatment.
Ulf Hermann, Software Engineer - Digia, Qt
Development mailing list
Development at qt-project.org
More information about the Development