For local run and GDB debug, with or without terminal.
Task-number: QTCREATORBUG-2831
Task-number: QTCREATORBUG-25330
Change-Id: I9b5d2156bcffea4f358474ecdbcad580a4419917
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is apparently the right thing to do anyway and also helps to
select the right emulator or device when multiple ones are connected.
In that situation otherwise an error
"Expected a single connected device, got instead 2 -
try setting 'ANDROID_SERIAL'"
would occur.
Change-Id: I650a221d1a321d4dd9035411f85c7a68244c20e2
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Might be useful to set ANDROID_SERIAL to get hold of the right device
when multiple are connected.
Change-Id: I8f1f02552a9f57ee8a9ed35ae696d137cc85fe52
Reviewed-by: David Schulz <david.schulz@qt.io>
Needed for setting up device connection later.
Change-Id: Ib794a8bf093714935b9a3ed3f290d46550763d68
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is mimicking a bit what has been done on the baremetal side,
and is formally more correct when the gdbserver is not a real
gdbserver, but e.g. a probe speaking the gdb remote protocol.
Change-Id: I1b42624b94071b34c009bd0650095792a5b2fcb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For cases where no genuine RunConfiguration is available.
Use it in the debugger for the cases triggered from the menu.
Change-Id: I5671f4f5db2547c4a7a70bd34292bb6ccc8e6bf4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is a step towards properly supporting multiple debugger
sessions side-by-side.
The combined C++-and-QML engine has been removed, instead a
combined setup creates now two individual engines, under a single
DebuggerRunTool but mostly independent with no combined state
machine. This requires a few more clicks in some cases, but
makes it easier to direct e.g. interrupt requests to the
interesting engine.
Care has been taken to not change the UX of the single debugger
session use case if possible. The fat debug button operates
as-before in that case, i.e. switches to Interrupt if the
single active runconfiguration runs in the debugger etc.
Most views are made per-engine, running an engine creates
a new Perspective, which is destroyed when the run control dies.
The snapshot view remains global and becomes primary source
of information on a "current engine" that receives all menu
and otherwise global input.
There is a new global "Breakpoint Preset" view containing
all "static" breakpoint data. When an engine starts up it
"claims" breakpoint it believes it can handle, but operates
on a copy of the static data. The markers of the static
version are suppressed as long as an engine controls a
breakpoint (that inclusive all resolved locations), but are
re-instatet once the engine quits.
The old Breakpoint class that already contained this split
per-instance was split into a new Breakpoint and a
GlobalBreakpoint class, with a per-engine model for Breakpoints,
and a singleton model containing GlobalBreakpoints.
There is a new CppDebuggerEngine intermediate level serving as
base for C++ (or, rather, "compiled") binary debugging, i.e.
{Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine
base that are not applicable to non-binary debuggers.
Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to provide a set of urls indicating usable connection
points for 'server-using' tools (typically one, like gdbserver
and the Qml tooling, but two for mixed debugging).
Urls can describe local or tcp servers that are directly
accessible to the host tools, if needed port forwarding
could be set up when needed.
Use it as new base for GdbServerPortsGatherer for starters.
Note: Since none of the customization points for actual port
forwarding are currently provided by device implementations
only non-forwarding cases are working right now. Incidentally
this does not affect existing setups, as the only case where
it would be needed (Android/adb) have a complete custom
implementation. The medium-term plan there is of course to use
this new setup here and have the AndroidDevice implementation
only provide the forwarding, not the whole debugging (etc...)
Change-Id: I42c9783348cd430b1c435bbca56329c678ac485c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... to a running application that already has one.
Task-number: QTCREATORBUG-19302
Change-Id: Id83f840408c26f3db85dbe30dadac9949ce6b660
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
The device is needed to properly interrupt the inferior with cdb.
Change-Id: I96f3a7393770be9821d8edd7123c458399d4494a
Task-nnumber: QTCREATORBUG-19253
Reviewed-by: hjk <hjk@qt.io>
Less code in the target implementations.
Change-Id: I759f082eba5eab7f4e8252c0d7b5ec64059ba860
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
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>
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>
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>
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>
... 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>
