This was part of very original gdbserver support where normal
remote debugging did not start the server on the device.
The effect can still be achieved by a custom deploy step.
Change-Id: I8763ea131700115065693bd8a8a5382f0e02a113
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... to take a function returning a FilePath as base.
Implementation is (not) yet changed.
Change-Id: I624efab35cf38631c816b630be5296bdf696899e
Reviewed-by: David Schulz <david.schulz@qt.io>
The main QtcProcess interface is nowadays a CommandLine, with no
explicit references left to QtcProcess::Arguments and related static
helper functions, so it only clutters the QtcProcess class interface
So move these items out of QtcProcess, later potentially to a separate
file pair.
Change-Id: I45c300b656f5b30e2e2717232c855fdd97c2d1d7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There can be modifications in the environment between the decision
to use a terminal and its start. We want them taken into account.
Change-Id: I5622614c5fac3bdd8167c29e7b618b5e42a28287
Reviewed-by: David Schulz <david.schulz@qt.io>
Debug output is ephemeral in nature, and does not belong into system logs.
It happens, however, on Arch. Let people override this.
Fixes: QTCREATORBUG-25421
Change-Id: I5686e256d76e5a127e3269c5f407daf39bad683f
Reviewed-by: David Schulz <david.schulz@qt.io>
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>
And AttachCrashedExternal to AttachToCrashedProcess
And AttachCore to AttachToCore.
Clearer.
Change-Id: I47c2eca5cbdbbc0eb38b9f62b2504c96558ff112
Reviewed-by: David Schulz <david.schulz@qt.io>
Fix the following warning:
qgetenv().toInt() is slow. Use qEnvironmentVariableIntValue()
instead [clazy-qgetenv].
Change-Id: Ifb5d3869e758f8c42bb9f34004d9c04d5dbb4d89
Reviewed-by: hjk <hjk@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@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>
We'd like to create more useful tasks from compiler output, that is, try
harder to identify consecutive lines that refer to the same issue and
create one task for them, rather than one for each line. In such
"aggregate" tasks, the first line will not necessarily carry the main
information. Therefore, we make it explicit what this main information
is by introducing a dedicated summary member.
Also streamline the font handling for compile tasks.
Change-Id: I933f2643a13c710dab1ab548c56669b129026eb5
Reviewed-by: hjk <hjk@qt.io>
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>
... when the debug server looks like lldb-sever.
Also use suitable arguments.
Needed for setting up device connection later.
Change-Id: Ie4130be7881e12d460ab5116b0018916d47ed012
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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: Iba4bd0d073ba74e10dd579f0115570ccd4189da3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Presumably, they were intended for output that shouldn't get an
automatic newline, but if there ever was such a thing as automatic
newlines, it must have evaporated over time. All users of
OutputFormatter provide a newline if they want one.
Change-Id: Ibd219b7305fd503ce075d6f77930d2b538d5e2e8
Reviewed-by: hjk <hjk@qt.io>
This patch adds debugger integration from the KEIL uVision IDE:
* http://www2.keil.com/mdk5/uvision/
This IDE has the uVision Socket Interface (UVSC) that allows
to the applications configuration, building and debugging:
* http://www.keil.com/appnotes/docs/apnt_198.asp
Besides, it provides a binary client libraries for Windows, which
are implements some API which we are use in this patch.
Currently implemented the following features:
* Enumeration of a stack frames.
* Enumeration of a threads (tasks).
* Registers view (read/write).
* Local variables view (read/write).
* Watchers view (read/write).
* Disassembler view.
* Current location marker.
* Break-points.
* Step-in.
* Step-over.
* Step-out.
* Step-by-instruction.
* Start/stop/pause/continue debugger.
* Auto-detection for the installed uVision instances (as debuggers).
* Wizard for choosing and configuring of the UVSC debug providers.
At this moment added support only for the 32-bit ARM devices, provided
by the STMicroelectronics:
https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html
For this are implemented two debugger providers:
* Simulator - allow to simulate the target device.
* ST-Link v2 - it is a HW debugger.
This implementation tested only with the QBS using the following
target boards:
* NUCLEO-F767ZI (based on STM32F767ZIT6 MCU).
* STM32F4DISCOVERY (based on STM32F407VG MCU).
* STM32F103x (based on STM32F103C8T6 MCU).
A more detailed information about this patch can be found in a
bug-tracker.
Fixes: QTCREATORBUG-23426
Change-Id: Ie36a1f7430b56c33d6665cc35e43fe9bd95d28f1
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@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>
... to filePath and setFilePath. In line with Utils::FilePath.
Change-Id: I7115b91876542629c3d61c8259bbd8d9f4022fc1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The Environment class is supposed to support values with references to
other variables, but we failed to actually expand them in most places.
Fixes: QTCREATORBUG-22687
Change-Id: I108cb59d3b4571471423455240f6f4f1cf64bf05
Reviewed-by: hjk <hjk@qt.io>
... taking a QString for the executable.
This weakens the very explicit QString -> FileName conversion via the
named constructors for the special case of constructing a CommandLine.
I think that's worthwhile here, as it reduces the noise on the caller
site under circumstance where the nature of the thing is obvious.
Change-Id: I27b4a73639728893d053b2e7ba65cb745f0ffe83
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Seems to be possible to trigger in a failing MinGW start on Windows.
Change-Id: Ica93c29ad677c24688a8cf2c5a0f1018471ffe51
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We regularly pass around strings or filenames or pairs of strings
or filenames and stringlist etc the in the end will be used
as a kind of "command line", with quite a bit of ad-hoc user
code and QtcProcess::addArg etc to set them up and manipulate them.
Let's have a class for that concept.
Change-Id: I288ab939d853b32c717135a65242c584c2beab50
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Looks like the mainwindow cannot be convinced to handle multiple
sets of dockwidgets.
So switch back to a single set containing everything and keep
track of non-default visibility in the perspectives, and persist
these sets.
The following pass:
1.
Start Creator with new settings
Goto Debug Mode
Move Break dock widget to right, switch on Global log widget
Leave Creator
Start Creator
Goto Debug Mode
Check: Debugger Selected, Break on right, Global log visible
2.
Start Creator with new settings
Goto Debug Mode
Move Break dock widget to right, switch on Global log widget
Switch to QmlProfiler sub-perspective
Leave Creator
Start Creator
Goto Debug Mode
Check QmlProfiler selected
Switch to Debugger sub-perspective
Check: Debugger Selected, Break on right, Global log visible
3.
Start Creator with new settings
Use any C++ test project
Start debugging / stop at main() (F10)
Wait for stop
Switch to Edit mode
Switch back to Debug mode
Check: Only "running" debugger dock widget layout present
(not the normal + preset at the same time)
Quit Qt Creator while this debugger is running
Check: Shuts down without crash
4.
Use any C++ test project
Start debugging
Switch to Debugger Preset perspective
Start a second debugger
Kill either instance
Check: Application dies, Debugger Preset perspective gets displayed
Switch to perspective of second instance
Check: Perspective looks ok (docks visible as before)
Task-number: QTCREATORBUG-21083
Task-number: QTCREATORBUG-21669
Task-number: QTCREATORBUG-21668
Task-number: QTCREATORBUG-21813
Task-number: QTCREATORBUG-21851
Task-number: QTCREATORBUG-22110
Task-number: QTCREATORBUG-22169
Task-number: QTCREATORBUG-22189
Change-Id: Ic9eb41ff7699ac0f48a85e68376daa80b2b6847e
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
