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>
Move engine creation closer to RunControl creation, One step closer
to switching orders and making the engine a RunTool.
Change-Id: I37e9c4fcca9381cc0b8fb14b98c892eef8cb1215
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>
That object is destructed soon, no data is ever read back.
Change-Id: Ida479c4dd934c6f45621b54adcfeda3f573a00bd
Reviewed-by: Robert Loehning <robert.loehning@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>
One step further to separate the debugger environment from the
inferior environment and to make it possible to configure a
working directory. Guessing one from the inferior's working
directory is not always a good idea.
Change-Id: I33d139c0f228ec0870556b82bc6aecca0a8e62d6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use that in the debugger. That simplifies the logic a bit.
Change-Id: Ia72607283373ee0f89a91f347db0ef2c87cf9fb3
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
The main idea is to start using ProjectExplorer::Connection later.
Change-Id: Ie91eacdfb0e93ae142fec7ce32bcf554a5282122
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on
QString is feasible again. Take this as opportunity to move
debugger encoding handling closer to a 'conversion on input and
output if needed, storage in QString only' scheme.
Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
