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>
This solves the ambiguity between 0 and -1 being the "invalid" port.
Change-Id: I3bac11dd4117bb1820fbd58186699925b73df1c5
Reviewed-by: hjk <hjk@theqtcompany.com>
Setting projectSourceFiles etc once is sufficient.
Change-Id: I340406e2f7de82bd9919aa9ec0ff1982b2118e59
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
... 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>
Core contains the small variants of debug run/interrupt/continue/exit
while the bigger icon variants are in projectexplorer or debugger. That
does not seem to have aany reason, at least in today's state of Qt
Creator architecture.
But above all, it stands in the way when changing debugger icons as
planned due to user feedback.
This change moves:
Core::Icons::DEBUG_START_SMALL
to ProjectExplorer::Icons::DEBUG_START_SMALL
Core::Icons::DEBUG_EXIT_SMALL
to Debugger::Icons::DEBUG_EXIT_SMALL
Core::Icons::DEBUG_INTERRUPT_SMALL
to Debugger::Icons::DEBUG_INTERRUPT_SMALL
Core::Icons::DEBUG_CONTINUE_SMALL
to Debugger::Icons::DEBUG_CONTINUE_SMALL
This change just moves icons across modules but does not change anything
in the UI.
Change-Id: I859b901c312d4d16b6c2f687395a7b48c90aab84
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
It's only used when starting with a -debug command line and
when attaching to a running run control. No need to clutter
the normal codepaths with it.
Change-Id: Ib374c64a7f63fa79e88967573c37a5da1f415d50
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
