Parts of the Debugger engine rampdown mechanisms are
essentially one code path now, don't distribute that
over four classes.
Change-Id: I4c6edbc0db94d1f658b0c1d9c154552f286db876
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
setUseTerminal was called before the engine was set. Reordered it.
Task-number: QTCREATORBUG-19056
Change-Id: I43f2aebaf72a904ea3a3bcf03cd41186b191b209
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Fixes a regression introduced yesterday with 58a69c461a.
Change-Id: I9eea3d0adf45e2b65b7d395280ae0e0fbbe01127
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It is a fixed value in the respective contexts, no need to track
this 'state' separately.
Change-Id: Id442202ff7a72baf5a2b19ba4bb9dfec5f47fb70
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Moving the knowledge that this won't work well outside windows
kind of decreases encapsulation, but that's not really worth the
complication of the error handling here.
Change-Id: Idcb6f6d64f33ee8c49a01e62e20aad16d3f01b86
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Allow to rely on kit plus data directly specified in the dialogs.
This means, RunControls with nullptr RunConfigurations are allowed
again.
Change-Id: I0b574b397603c0520c8187a8967bff2cf5e20ae8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The idea is that they shouldn't change after start() to
be re-usable for an additional run later.
Change-Id: I272fc975657b0d8b5b13a07d58bd0b626868d32e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There was almost 1:1 overlap with DebuggerRunTool::is{Cpp,Qml}Debugging,
use one version only.
Change-Id: I4a8f2b7005d3f2e440cdab3eaf6ac476af894308
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Harm was limited, as these were the fallback values for terminal
and working directory that are overridden in all cases with
real RunConfiguations.
Change-Id: I7d3cef1ac814a0ffcf60a8977e0ae13136ea50b5
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The idea is that the fixup should not be needed at all anymore,
instead, static data coming e.g. from the RunConfiguration should
be setup in the constructor, and everything else should be ready
at entry into start().
This also proceeds on path to the planned-but-never-implemented
idea that the RunConfiguration should (at most) be accessed at
RunControl creation time, not later.
Change-Id: I04d622785f5de628a7bb479bc0c39aff7d6cce01
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Only works for opened, active project, but better than before.
Change-Id: Icafe3a9605cea29cd16ed4bd316bf195e78efdb5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
It's all coming via individual setters now.
Change-Id: I373f43963e696fa7223f9d664de1df1bc8b021e5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The users (typically target specific DebuggerRunTool derived classes)
are meant to use the individual setter functions nowadays, not the set
up the full structure, so the members are a true implementation
detail now.
Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... 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>
