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>
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>
No need to depend on RunControl life time here.
The isRunning test is already done outside sufficiently often.
Change-Id: I3b33444df6092f52b186bbf3a58585ad0bbb03bb
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 debugger specific code and less convoluted paths in debugger
message handling.
Change-Id: Ib298889c386d65f17acbdfc585188097bb20ed74
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It is redundant, as a RunControl has a runMode() getter.
Change-Id: Ia048b271a5003356d21f86a3f778827d23466037
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Only one code path needed once we have a RunConfiguration.
Change-Id: Ib65f471a929a0c70694dd142b4f83be7eebbe151
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Less coupling than using virtual functions for better re-use.
Change-Id: Ibbab38175538f65c0f563129c87e01736ed220af
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Makes using code closer to the intended run control/tool setup
pattern.
Change-Id: Id898338008588227e778fe3835b96740996c3691
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>
