Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
It has been an obsolete alias for setId for a while and downstream
uses have been adapted.
Change-Id: I467370aa67054599c7771e8275d28e62ddc461fa
Reviewed-by: Tobias Hunger <tobias.hunger@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>
The actual remaining use was to pop up a terminal in some
setups where Mode == Console, with a default of Gui meaning
"no console". In some downstream uses it was used set to
Console (probably to mean "this helper process does not need
a gui") but then luckily ignored when actually starting the
helper processes.
All cases where the console is useful and requested are
nowadays RunWorkers belonging to RunConfigurations with
a TerminalAspect, so they can directly get the relevant bit
from their RunConfiguration without having it part of
all StandardRunnables.
Change-Id: I1368d5968da5cf672656aebf200ccac8d45335d0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
DebuggerRunTool and debugger backend process have (almost) a 1:1
correspondence, unlike engines or the debugger plugin itself.
So it makes sense to accumulate backend start/rampdown login
in DebuggerRunTool.
Change-Id: Ia105283bcdf2641c7e9a401b4146b34c20605ba7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This simplifies code and reduces the number of conversions between
QString and Utils::FileName.
Change-Id: I47bd86b9ae09b1da37b4e5e604761367ac1ab26b
Reviewed-by: Ulf Hermann <ulf.hermann@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>
This is/will be optionally available independent of the concrete
run configuration type, so use it.
Change-Id: Ife0e906ff47e916d2f7a9df73af8cdd83635cd65
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Combine host, port, username and password into a 'url' member and
add some convenience accessors.
Change-Id: Iddc26ff00dad1285c96aa56f196dbc4febe8e974
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>
Same (or similar, in case an explicit path is configured) message
is triggered by the base class, no need for duplicated here.
Change-Id: I1a3e3c386674e98dc0ddd31f1156f7e8254a53c2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The device is needed to properly interrupt the inferior with cdb.
Change-Id: I96f3a7393770be9821d8edd7123c458399d4494a
Task-nnumber: QTCREATORBUG-19253
Reviewed-by: hjk <hjk@qt.io>
When neither c++ nor qml debugging is enabled in the run page the
debugger wont start. Print a message to the Application Output pane
describing where the setting is located that enables debugging.
Change-Id: I580139e62c0fb0f4ae518ce818738165b80f8e0c
Reviewed-by: hjk <hjk@qt.io>
It's always needed and GdbServerRunner knows the PortsGatherer.
This also makes the setup more similar to the QNX PDebugRunner setup.
Change-Id: I5863d2c77cd5c92d0f25682d655c9901b8939c30
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>