Needed for setting up device connection later.
Change-Id: Ib794a8bf093714935b9a3ed3f290d46550763d68
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It could be lldb-server at some time, too.
Change-Id: I5a8210e05189902d1cef9b41e14df0b585bcb86b
Reviewed-by: Christian Stenger <christian.stenger@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>
If the inferior stops by itself and the debugger
tries to shutdown it had ended up waiting forever for
the additional workers (e.g. ports gatherer, channel
provider,...) to stop.
The debugger appeared as finished but the runworker was
still in a running state until the user would hit the stop
button of the application output pane.
Make the gdbserver essential to initiate a clean finish.
Change-Id: I16b2ebe5feadc88bb76ce34b49ac5d3456d0867c
Reviewed-by: hjk <hjk@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 possible now that the remote process is started via a local
tool.
[ChangeLog] Remote Linux applications can be run in a terminal now.
Change-Id: I9f7df87563a18880d85c6d16ad18fb10a4d9f0e0
Reviewed-by: hjk <hjk@qt.io>
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/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>
The basic idea is to provide an easy-to-configure reusable
building block to provide an "Executable" in a run configuration.
This patch here extracts some generic from the previous
ExecutableAspect into a BaseStringAspect and bases the new
ExecutableAspect implementation on it. It also adds the
the ability to make it editable or to manually override an
executable, and adds a SymbolFile aspect for the accompanying
sources of debug information.
Use in RemoteLinux and Qnx for starters and demonstration purposes.
In the end the Qnx runconfiguration widget does not depend on the
RemoteLinux implementation anymore by replacing the previous
code-sharing-by-inheritance by direct (and less) code.
Change-Id: I91b55820455256a8526e39458364b6cb74e63cd7
Reviewed-by: Tobias Hunger <tobias.hunger@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>
There was only the now-unused FifoGatherer left, which could, if really
needed again, be re-instated near the actual worker that would need it.
Also, un-export LinuxDeviceDebugSupport and RemoteLinuxQmlProfilerSupport
which are not re-used, and conceptually not meant to be re-used, anymore.
Change-Id: I20b6eb2f4a85180b586ea8338cf74173e3b7b21c
Reviewed-by: Christian Kandeler <christian.kandeler@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>
There will be stopDependencies, too, which apply when stopping the
runcontrol.
Change-Id: Id72771d28cbb6b254572c9f93db93e0d054b890f
Reviewed-by: hjk <hjk@qt.io>
It looks like the case where workers need talk to each other by
only knowing the type of the 'partner' does not exist in practice
anymore. With the now-common setup of a 'primary' worker that one
can introduce the 'lesser' workers to each other directly.
That's also conceptually more robust that picking a partner by
type only only from some 'pool' (all the workers in a runcontrol),
scales better (it e.g. is imaginable that a RunControl needs
more than one PortGatherer in complex setups where more than one
device is involved) saves a few cycles, and even removes the need
for workers to be qobject_cast-able.
Change-Id: Ib3d8c942c893d6c198d9813cce7df28ba3260ce8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Not needed anymore in the world of RunWorkers.
Change-Id: Id7fb24fece6acb03de12f2677dd99a05c513e7a4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Vikas Pachdha <vikas.pachdha@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>
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>
Aim is to replace it with its ProjectExplorer::RunControl base.
Change-Id: I30f837050e7c016887dc4b6cfef10b947f4f88ed
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This essentially just puts the data members and most of the original
interface on the proper, i.e. the 'target', side of the tool/target
divide. Since the SimpleTargetRunner base already has an
ApplicationLauncher member, this can be used directly.
State handling and coordination between tool and target runner parts
stays as before for now, with unchanged 'custom' transition logic.
The plan here is to remove the custom state handling later, including
the two remaining cases of direct targetRunner->toolRunner calling
(startExecution, and adapterSetupFailed) for which this patch here
temporarily uses signal/slot connections.
Change-Id: I664f2e333b48b582befd0531a17d4008acac7c4c
Reviewed-by: Christian Kandeler <christian.kandeler@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 good first approximation and often enough all that is needed.
Change-Id: If54cdb0e98cda94bc4a4ef24fcc12c78018c4dbe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This continues the quest started with eb0b0f944.
This also moves the AnalyzerRunControl::starting signal to the
base, similar to the already present started and finished
signals. Moving emission of the signal to the base is left
to a follow-up patch to keep this here small.
Change-Id: I12e04823df22e7667a4d0a9ee7412153180c60cc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Add a hook to augment a runnable by derived classes in order to
remove the code duplication in qdbdevicedebugsupport.cpp.
Change-Id: Ia374e45ce1c58f751cec2cd1ff2ee324c010afe3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Treat ApplicationLauncher as a special case of a DeviceApplicationRunner
with an implicit desktop device.
As a first step, lump the two implementations together.
Change-Id: Ifa3ea3f38d320023050378555e2d256e762b6683
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
In preparation of merging the class with LocalApplicationLauncher.
Change-Id: I190f8da34a2420061f05ccf4a9fdd428c2a2c57b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Rename the "GatheringPorts" stage to the more generic
"GatheringResources", and don't do it by default on
handleRemoteSetupRequested(). Also, drop a few asserts that tested
specifically for QML Profiler.
Change-Id: I53c3182d237f53e6dda20cd1c856e7e5f951e90e
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
This solves the ambiguity between 0 and -1 being the "invalid" port.
Change-Id: I3bac11dd4117bb1820fbd58186699925b73df1c5
Reviewed-by: hjk <hjk@theqtcompany.com>
This is almost uniformly used everywhere else.
Change-Id: I1ef9abb24066b21652aeb994b18ea3e19f48b3c6
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
The cases handled here are later handled using generic code in
DebuggerRunControlCreator::enrich().
Change-Id: I03de1d5378718019afdb046f4446bb46a97ddee6
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
We have tcp, local, and native by now. We have to expose that in a
clean way.
Change-Id: I0ce7be693aa7f47ebea7abe435a224a176b6c94b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The services need to be loaded before the first QML engine is created.
The first QML engine may be created before a client connects. When the
JavaScript debug service is loaded the engine is put into interpreter
mode as we don't support debugging in JIT mode. Profiling, however
should be done in JIT mode, whenever possible.
Thus, in order to avoid the loading of unnecessary plugins and to get
better results from the QML profiler we tell the debug server which
services we expect, even before the client connects. Qt 5.6 will support
additional command line arguments to specify the services and this
change uses them.
Change-Id: I6dcee016c39995e9adada6eaf0e39d8299c9b7e7
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
- Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters,
they are always the one coming from the kit.
- Move projectSource{Directory,Files} to DebuggerRunParameters,
they are alway coming from the runConfiguration's project
- Pass RunConfiguration always as separate parameter, that's
what related code does.
Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
next if file =~ %r{src/shared/qbs|/qmljs/}
s = File.read(file)
s.scan(/^using namespace (.*);$/) {
ns = $1
t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
before = $1
char = $2
if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
m
else
before + char
end
}
if t != s
puts file
File.open(file, 'w').write(t)
end
}
}
Change-Id: Id48e46fdfed83b82071551f4375fab3310ed1f6e
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
