The original version might have missed to recognize a @\r\n
combination or multi-byte UTF-8 code units when they were
split across to readyRead() handlers.
Change-Id: Ib543fa0070b63d25b44be429a3759964d65e878e
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
appendOrSet will append to existing environment variables which is not
what we want for all the changed locations in this commit.
Change-Id: Icf6b110acc59261659839375672943ec21923da1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
lldb will normally set OS_ACTIVITY_DT_MODE, so that NSLog is mirrored
to stderr, but this also affects os_log, which we use in the Apple
unified logging backend.
When we detect this situation in the unified logging backend, we disable
Qt's own stderr logging, to avoid duplicate messages.
As the Qt stderr logging is preferable to the stderr logging that os_log
gives, we override lldb's choice, using the same environment variable
opt out that Xcode uses: IDE_DISABLED_OS_ACTIVITY_DT_MODE.
This makes console output in Qt Creator the same, regardless of whether
the user is debugging the app or not.
Change-Id: I5544bde803671258cede918705388c9283885e30
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
When starting a local debugging session and the terminal is not used, no
reason to assert that the remote pid is not valid etc.
Change-Id: I1b62a98721425784ca80ce9261b07475c19f3ba1
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Instead of relying on __name__ being 'lldbbridge', which can also
be the case if the lldbbridge.py script is imported into a plain
LLDB process, we can now look at the environment variable.
This also lets us break out early from __lldb_init_module
if the user has a `command script import llbdbridge.py`
in their .lldbinit, or is automatically loading the bridge
via the Qt Core debug script.
Change-Id: Id8168c692ef66ce50119b7426ca85c7bc99d9503
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is fairly close to the new "standard" pattern for an
individual page but still allows flat access using the same
'settings().' stanza.
Change-Id: I1edbbd64a857a3d3936fb2c21fdc7e3c8ae7a44c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
This allows using dumpers available on the host being used from
remotely running gdb. No lldb/cdb yet.
Task-number: QTCREATORBUG-29000
Task-number: QTCREATORBUG-16246
Change-Id: Ib1a40a8c0284dcf41e8800d70ca3e632c699b2fa
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
