[Development] new "debugsupport" module and API

[Hartmann Thomas]

Hi,

I guess using a TCP connection would still be possible, but not be the defaut anymore for local debugging/profiling?

Kind Regards,
Thomas Hartmann
________________________________________
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

Hi,

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:
- qtdeclarative/src/plugins/qmltooling/shared/
- qtdeclarative/tools/qmlprofiler
- qtquick1/src/declarative/debugger
- qt-creator/src/libs/qmldebug

We have differently named but functionally largely identical
implementations of the qml debug client and connection in:
- qtdeclarative/tests/auto/qml/debugger/shared
- qtdeclarative/tools/qmlprofiler
- qtquick1/src/declarative/debugger
- qt-creator/src/libs/qmldebug

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
plugins.

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
qtbase:
https://codereview.qt-project.org/#change,85098
https://codereview.qt-project.org/#change,85099
https://codereview.qt-project.org/#change,85100
https://codereview.qt-project.org/#change,85101
https://codereview.qt-project.org/#change,85102
https://codereview.qt-project.org/#change,85103

I also have some WIP changes for qtdeclarative to use debugsupport:
https://codereview.qt-project.org/#change,84103
https://codereview.qt-project.org/#change,84527

And for QtCreator:
https://codereview.qt-project.org/#change,84526

QtQuick1 will get the same treatment.

--
Ulf Hermann, Software Engineer - Digia, Qt
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development