... 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>
... 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>
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>
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>
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>
Note that this changes the startup timing in the StartupOnNetwork
case slightly, as the application launch is now triggered in
parallel with the gdb launch.
Change-Id: Iaa0b60b8c478eb47abb6e93fbd3b326e0acdd13b
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Christian Stenger <christian.stenger@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>
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>
Remove some now-unusual connection to RunControl::finished
and use a finished() callback in the ToolRunner implementation
instead.
Change-Id: Ieddf05a2258d9a300ac50a739d77d9cfaee10ca6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Basically all derived tools will need access to the debugger aspect
data. Fetch it once.
Change-Id: I054e4255a036db258201a8a501af244206c06990
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Add some customization hooks to make tools aware of target errors
and vice versa.
Change-Id: I4d815087297a3fa1d1d6d52daeed7c4ae0f624bf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Aim is to replace it with its ProjectExplorer::RunControl base.
Change-Id: I30f837050e7c016887dc4b6cfef10b947f4f88ed
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's tool specific, so put it into the tool (only) related code.
The additional level of indirection will go again, plus the original
one will be removed once the *DebugSupport classes can directly
use DebuggerRunTool as base.
Change-Id: Ieaa386a0f7d724b09cedaaba8fb7d1e6dc4ad55b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
That's a temporary move to be able to port the per-target
Debug*Support classes one by one.
Change-Id: I3cf5f9ea367a68058add8713ed23f44da080a175
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This (temporarily) works around the start up regression due
to wrong order of merged patches.
Change-Id: I7a386fb06175363aa23862716687764b930c52d8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Less coupling than using virtual functions for better re-use.
Change-Id: Ibbab38175538f65c0f563129c87e01736ed220af
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Make DebuggerRunTool accessible to downstream users, but remove
the non-standard handleApplicationOutput from the run control
itself to move it closer to the base run control.
LogChannel and Utils::OutputFormat should merge at some time.
Change-Id: I47b0f0067e1427b25e47036c3d4bc6ed5eed6189
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The DebuggerEngine cannot be promoted directly as in case of
combined debugging we have three DebuggerEngine at the same
time, but the base RunControl is only (and should be) able to
handle one tool. So introduce a DebuggerRunTool base-RunTool
derived class that's only a thin wrapper on the (master)
DebuggerEngine.
Change-Id: I948833f4cff68c7d6e3dfa43b28328b862d6ae81
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The same functionality is available by using signals of the RunControl.
This reverts ca3bcd81 partially.
Change-Id: Id1d4d6e8326be60cdbe7c862dab46f49dbc6abe7
Reviewed-by: hjk <hjk@qt.io>
The indirection was to prevent "others" to create "wrong"
DebuggerRunControls, but this is getting into the way now when
making the DebuggerRunControls/DebuggerEngine a ToolRunner.
Change-Id: I6c45e28affebc6b8db16c5d4bbc77325ef63604f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This introduces a mini-state-"machine" to handle RunControl states
Intialized->[Starting->Running->Stopping->Stopped->]*->Finished.
Needing time between trying to start and getting feedback is nowadays
the normal setup for all remote targets as well as for most local tools.
Making that the default for all runs simplifies the code and provides an
opportunity to (a) fix some currently wrong reports of "stopped
immediately" and (b) to remove target-specific (WinRT) or tool-specific
(Valgrind, GammaRay) state members doing essentially the same.
Change-Id: I7f52fee41144188ee8389e922fdc265f8c0a6459
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Provide protected methods in RunControl to handle the notification
of when the RunControl starts and stops. Use these helpers to
move the isRunning() method into the RunConfiguration itself instead
of reimplementing it everywhere.
Change-Id: Ia8de42f7a6a14a049870d4e7fcb9af6756c2caa4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Output coming from the debuggee was limited to be printed inside
the DebuggerLog and the Application Output pane, but the output
might be useful to process differently or even additionally to
the default logging.
Provide functionality to be able to add an output processor.
Change-Id: I715b90b28c64d3cf95bcc2a047a5aba1a56d1058
Reviewed-by: hjk <hjk@qt.io>
... for QML engine, which currently does not handle state
transitions in that case.
The normal debug button (or <F5>) of course still work for
starting to debug the current project, which is in most
cases effectively the same.
Change-Id: I02ebf989030a6eb7ff919add6ccc20e7230d9cc1
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
Sprinkle overrides over code derived from classes in ProjectExplorer
Change-Id: Ia4cc25649f7dc00b0ea126d8176a59afbc5ed574
Reviewed-by: hjk <hjk@theqtcompany.com>
This provides a way for third-party plugins to implement run
modes without the need to add a value to the central enum or
using manual workarounds like RunMode(*(int*)&someUniqueObject).
Instead of centrally defined enum values this uses Core::Id that could
be defined anywhere.
Change-Id: Ic350e3d8dbb8042c61b2d4ffec993ca151f53099
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
