Previously lldb never actually attached to the process running
in the terminal, but started its own copy.
Since the process is interrupted by the terminal stub already,
code was added to automatically continue the process.
"Start and break on main" and "Run in Terminal" also did not work
together and are now fixed.
Change-Id: Iaeb6e7dd0f511f3bf195ab5d0008856b310615d9
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
By issuing "threads" the jdb will output the names of the running
threads. This makes sure that jdb has "settled" and is in a running
state.
Task-number: QTCREATORBUG-26592
Task-number: QTCREATORBUG-26709
Task-number: QTCREATORBUG-28141
Task-number: QTCREATORBUG-28428
Task-number: QTCREATORBUG-28851
Change-Id: Ib371e333eb9fc4d93a6b797bf7be68793f887fcd
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
... and re-use the old QtcProcess::readAllStandard* names for
a QString-returning 'decoded' version.
For now, only use that in 'full Utf8' cases, to stay bug-compatible,
the plan is, however, to employ the QTextCodecs we have already
in the channel buffers. That will be one-by-one, though.
Change-Id: Id209e0671920d4ea4197918e872f441254112d52
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
It's better when the user code has to be explicit in what
format and/or which parts of the FilePath is needed.
Change-Id: I9d70e073f853a1bbc47c8482ebe77d7c4612b4b7
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Side-effect is the stabilization of the order in which the paths are
passed to the debugger (was random, before).
Change-Id: I2dba3ae6f2feef57b26eab93dee0903ee2f93dde
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
And instead of qgetenv.
Takes Qt Creator's setting at "Environment > System > Environment" into
account, which makes it easier on some platforms to set them (e.g.
macOS), can be configured differently in different settings paths, and
potentially can be changed at runtime (depending on usage).
Change-Id: I3ea7623fb528e13a202afa2f89b00e5ee83962d8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Connect to started() signal instead and continue
setup in its handler. Handle failed to start case
inside done() signal handler.
Change-Id: I2c2eb14bf2948c23bae1e35a7581f52d25ab1dd4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
LLDB 12.0.8, which is included in NDK 23.1, hesitates to termiate when
being told to. Calling QtcProcess::stop() and using CtrlCStub on Windows
helps with that.
Amends: 17ff9317cd
Fixes: QTCREATORBUG-27723
Change-Id: Ie9d4ed23a833019f445c1517983c90ae899fbf39
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
LLDB 12.0.8, which is included in NDK 23.1, hesitates to termiate when
being told to. Setting UseCtrlCStub to true helps with that.
Fixes: QTCREATORBUG-27723
Change-Id: If14f196cc18f0c6943b59702aca117101b66d02c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Centralize some boiler plate and warn about best-guessed cases.
Keep the QByteArray based access as writeRaw()
Fixes: QTCREATORBUG-27445
Change-Id: I948d80fba78b36cf85cc73664175ab05eb7707d4
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
This includes replacing DeviceProcess terminal handling with base
member.
Change-Id: Id1541bfce33c71dddc71b4816ad0b174dce3879c
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Not just to deduplicate/reuse code but also to make make it clear that
different places where lldb is called, the same preparations have to be
done.
Change-Id: I104aca845fd7b42f63443bda2502574f4d28b411
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
And pull the env-modifying code into a function which we might want to
use in other places where lldb gets executed.
Change-Id: Ic9caaf8c29896c54d67c969d2812b4da627a5fc0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Uses the right python version and connects. but the device
side keeps saying "Waiting for Debugger".
Change-Id: I0bc9dadfa9e12831006cd486984bc29e197d7fbd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This patch needs to be applied together with the parent change.
There are 3 basic cases:
1. The user doesn't write anything to the write channel:
You don't need to call closeWriteChannel manually anymore.
By default the QtcProcess you create is in ProcessMode::Reader mode.
Internally it opens the process in ReadOnly mode and
closes the write channel just after starting.
2. The user writes some initial data (after being started)
and then closes the write channel:
All what is needed now it to set the write data
(QtcProcess::setWriteData) before calling start.
You also use the default ProcessMode::Reader mode.
Internally it opens the process in ReadWrite mode
and writes the writeData asynchonously when the process
already started. After writing the data it closes the
write channel automatically.
3. The user writes the data also after calling start.
All you need now is to create a process with
ProcessMode::Writer mode. In this mode the write
channel is not closed.
Internally it opens the process in ReadWrite mode
as some writers also read the data from the process.
All the code base is adapted here to the above rules.
Change-Id: Id103019d1d71a3012fd1eade226fe96b9aaa48c2
Reviewed-by: hjk <hjk@qt.io>
When Qt Creator is built as an Intel binary, and runs on
an Apple Silicon (ARM) Mac, it will be run via the Rosetta
translation layer. This means any process spawned by QtC,
including qmake, CMake, and lldb, will launch as x86_64
binaries as well.
For qmake and CMake, this affects their default choice of
build architecture, resulting in x86_64 builds of user
applications. We want to produce native arm64 apps, even
if Qt Creator itself isn't one, so we explicitly detect
the situation, and if Qt has an arm64 slice, we default
to arm64 builds.
The logic of adding CONFIG+=x86_64 to the qmake step has
been disabled, as the assumption that a single qmake run
and build will produce only a single architecture does no
longer hold. The corresponding logic in Qt was removed
in 2015 (qtbase f58e95f098c8d78a5f2db7729606126fe093cbdf).
In the case of lldb, running it as an x86_64 binary fails
to attach to the running application. We work around this
by using the 'arch' tool to explicitly launch it as an
arm64 binary. This works for debugging both arm64 and
x86_64 applications.
Change-Id: I65cc0f600223990f25c76cef18d927895e551260
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Mid-term plan is to concentrate on use of QtcProcess::result()
instead which is a bit more system-agnostic.
There's quite a bit of potential for downstream cleanup by
re-using QtcProcess::exitMessage() now.
Change-Id: I3806b3f5933d96e64b7cfb18cc6c52823fddcbcd
Reviewed-by: Christian Stenger <christian.stenger@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>
Saves some code on the user side.
Change-Id: I32cd220b6e533f5497a1865f9c34ab9db4cfda79
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
And AttachCrashedExternal to AttachToCrashedProcess
And AttachCore to AttachToCore.
Clearer.
Change-Id: I47c2eca5cbdbbc0eb38b9f62b2504c96558ff112
Reviewed-by: David Schulz <david.schulz@qt.io>
The lines between engine setup and running have always been
blurry, so it looks more and more unnatural to enforce this
in the architecture. Remove the runEngine() call from the
end of notifySetupEngineOk, and do it on the user side.
Change-Id: I3a5e158e8b3fe9b0a288d064f798e24b2ac47f86
Reviewed-by: David Schulz <david.schulz@qt.io>
Dead code since 3b5ecac238 (the end of the hybrid engine).
Change-Id: Ibb169ff657c8a88fdc52783a6a1f5b79fa0b29e5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
First mechanical step here is to derive SavedActions from BaseAspect
instead of QAction.
Change-Id: I2ec95883b825462c1d867f83cc2b3bd2c2732055
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For some reason, sometimes LLDB misses the first character of the next
command on Windows.
Task-number: QTCREATORBUG-14539
Change-Id: Ide78e0a0aa64ea4cbcaf6b55a0acdd548a1fa46c
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This could be extended to the other bridges, not done in this patch.
Change-Id: I620290049b7c95f8e3fb7584d4ca99a42fd343d4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The original reason for this was gdb's inability to set certain
break point properties in one go (commands and so parts of the setup are async
anyway, and using only async paths made the overall setup simpler.
The need to tweak some properties asyncronously still remains, but
for the caller side it's better when at least the initial round is
synchronous.
Change-Id: Ibe542533a6026c7f0f4e49f4244b7e9d2aea7062
Reviewed-by: David Schulz <david.schulz@qt.io>
Breakpoints inserting is async, so they did end up when the process
was running already.
This adds an extra roundtrip. Better, but more intrusive solution
might be to set the initial breakpoints synchronously, but that
would touch all engines.
Change-Id: Ia728a9c5ae8f1d6d29d3cc02b9e2d04952091fe9
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
