... a step towards abandoning the engine-related bits of
the debugger state machinery. The base RunWorker states
meant for that are good enough now.
Change-Id: I3b269bdeb66f14a956b76e6a7e8258f45b3e59e5
Reviewed-by: hjk <hjk@qt.io>
It was a recursive wrapper taking too many arguments to handle
what is at most a two-stage linear process. Making that explicit
is shorter and clearer.
Change-Id: Ibcb3422ff29b36b2b4df174fcffa8af62c254701
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... into DebuggerRunTool creation and explicit RunParameter bulk setting,
which later is to be replaced by setting individual parameters.
Change-Id: Ic4d2c6d10d659287ae61fdb4db735e658e3a68ce
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Even if this is LLDB-specific having the value fixed early
will help in moving terminal handling into a RunWorker
of its own.
Change-Id: I73a9564148dec9b28557c12cc248a4f0b668f8d7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The idea is to use them later to make the DebugRunTool setup leaner.
As proof of concept, use the new interface in LinuxDeviceDebugSupport.
Change-Id: I045ba4d05cfc56a9e875fd4461e9f562153872dd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Host and port reasonably belong together, using a QUrl makes that more
explicit and follows the lead of the Qml profiler in that area.
Change-Id: I754cb17d165ce6b2f25c655eeebfd8ac8f5a93c7
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It's currently only used via Debug->Start Debugging->Attach
(misnomer...) to running debug server, and only honored by GDB.
Moving it to a separate, centrally created worker makes makes it more
widely available and reduces the need for 'custom' handling in
the GdbRemoteServerEngine.
Change-Id: I39de7a5d8b64fc35d4bf93878e38c1866db90379
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... which should not exist to start with, and interferes in some
cases where the user code knows better.
Change-Id: Ie0b0038af3a4056fad8655d06f677fc800c99f8d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
To be used for short-lived tasks to signal that they are done.
Essentially an optional reportStarted() followed by reportStopped()
Using it in GdbServerPortsGatherer when the port list is ready fixes
the wrong "un-stopped" situation in RemoteLinux debugging when
the inferior finishes by itself.
Change-Id: I310831a7875fe6f2c598302b73cda6c9669efb1d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
If the project was not parsed yet while the debugger is invoked,
activeRunConfiguration is still null, so the debugger doesn't start.
Task-number: QTCREATORBUG-18551
Change-Id: I02d77fa8fb1b2a3673da5cbf28ea36156498918c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
If the startup project doesn't support the chosen kit, it fails.
Task-number: QTCREATORBUG-18606
Change-Id: I745768e7e9ee1740dadaae05d02dcc45f9e9ebef
Reviewed-by: hjk <hjk@qt.io>
Aspect creation must stay for now as the object pool is the only
central registry for it right now.
Change-Id: Ibe42009db6b0351aaa36e9ac8f0f6f7a0562167e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Let the workers keep track of errors instead of passing around
string pointers in some but not all interesting places.
Change-Id: I3956bc947a50747dd3a0c9302b9f9873d192e9c6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
A RunControl is re-runnable if all its workers are,
a RunWorker is re-runnable if it's Stopped and unless it
says otherwise.
Also ensure SimpleTargetRunner only reportStop() once
per run and make process error message re-usable.
Change-Id: I73f5fb724d3026ceb81d5e32a3a71b4814b2bca9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Not in start(), when it would add extra connections on each re-run.
Change-Id: I5fe9e047a188276f3bde54227dc0509ab77366c4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Makes remote output appear again in the Application Output pane,
and is arguably the right thing to do anyway.
Change-Id: I05c365eec43f60a85482b8ae7d5856b3a31ee6f8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It looks like the case where workers need talk to each other by
only knowing the type of the 'partner' does not exist in practice
anymore. With the now-common setup of a 'primary' worker that one
can introduce the 'lesser' workers to each other directly.
That's also conceptually more robust that picking a partner by
type only only from some 'pool' (all the workers in a runcontrol),
scales better (it e.g. is imaginable that a RunControl needs
more than one PortGatherer in complex setups where more than one
device is involved) saves a few cycles, and even removes the need
for workers to be qobject_cast-able.
Change-Id: Ib3d8c942c893d6c198d9813cce7df28ba3260ce8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Remote CallGrind is still dysfunctional.
Change-Id: Ib9ab537dc068c94c7e61ac48b1a4b9d655ccb60f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's nowadays a duplicate of a subset of what DSP::remoteChannel
provides.
Change-Id: I95363bd392cb1d24fb1f1e0a2780c2c295929cea
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Not needed anymore in the world of RunWorkers.
Change-Id: Id7fb24fece6acb03de12f2677dd99a05c513e7a4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
This moves all of the RunControl implementation into a single
RunWorker, not yet splitting it up into separate RunWorkers
which is the final goal of this series.
Change-Id: I7373105603505aa4fffd7fe5ff0145f0128b34bc
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The device is always available via runTool().
Change-Id: I4a2a791a5a75b32803c06fc34947b82b869fe31c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Keeping it as one blob for now, a proper split in the new architecture
would make WinRtRunnerHelper a RunWorker, too.
Change-Id: Ie310d05c1edf0ef9544b80743c140e44fcffc3ae
Reviewed-by: David Schulz <david.schulz@qt.io>
There were only two used target states, and in case of mixed
debugging all parts of the machinery better agree on the
direction. So one bool in the (shared) runTool is sufficient.
Change-Id: Iffbf1651b82dde707cfc37d8da9d3da573b34b76
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The parameters belong to the run control, they should not
be triplicated in case of a combined engine.
Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This increases re-usability of activities like 'port gathering',
and makes their use less dependent on actual device implementations.
Change-Id: I017cb74874f2b38c487ba2d03906a675d5618647
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Forward all tool and target activities to run control, and initiate
further state transitions (only) from there. Also, make sure
tool/target's on finished() triggered on all finishing code paths.
After that, the base state handling is sufficient to handle remote linux
running and debugging.
Change-Id: I0150ef249c9ad0b7b8ac7192be6dc860c9ca8fc5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
