| Commit message (Collapse) | Author | Age | Files | Lines |
---|
||||||||||||||||||||||||||| | If a process is being debugged from within Qt Creator, the Qt Core lldb helper script should not try to load the lldb bridges from each Qt Creator installation that has been found, because the main Creator's lldbbridge.py was already loaded, and trying to do it again would just return early. In some cases that could even silently break the dumper helpers if a bridge of an older Creator is loaded, because of the side-effects of importing lldbbridge.py. Detect that lldb was launched by Qt Creator via either the QTC_DEBUGGER_PROCESS or the QT_CREATOR_LLDB_PROCESS variables being set. The former is set by Qt Creator 14 and earlier, the latter is newly introduced in Creator 15. Add an opt in to force trying to load the bridge if the QT_FORCE_LOAD_LLDB_SUMMARY_PROVIDER environment variable is set. Pick-to: 6.8 Fixes: QTCREATORBUG-31769 Change-Id: Id59ed71f1e59c6c430bc0c72eb30a075db5fa603 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
||||||||||||||||| | So that it's easier to troubleshoot why a certain bridge might not be loaded. To enable verbose debug messages, set the QT_LLDB_SUMMARY_PROVIDER_DEBUG environment variable to 1 when launching Qt Creator or lldb. The informational message to set the env var is also shown if no bridge was loaded successfully. Pick-to: 6.8 Task-number: QTCREATORBUG-31769 Change-Id: I53e7b26950fdd635e51d0458cb5fb90600b158a2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
|||||||||||| | According to QUIP-18 [1], all tools file should be LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0 [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: Icd5d5be2e04819617e68ff142924de1773bebbad Reviewed-by: Kai Köhne <kai.koehne@qt.io> |
|||||||||||||||||||| | According to QUIP-18 [1], all module files should be LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only or LicenseRef-Qt-Commercial OR GPL-3.0-only LGPD and non-LGPL licenses should not be mixed in a given directory. The files in this patch are the only ones in their directory with non-LGPL license. The license is changed to that of the other module files in the same directory. [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: Id58248a6f60438e01e77e9448f07e3057d173260 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> |
|||||||||||| | For some reason mdls fails to resolve the kMDItemVersion for Qt Creator in some cases, even if the Info.plist has the required version keys, and the version shows up fine in Finder. Work around it by manually reading the version from the Info.plist Fixes: QTBUG-117204 Change-Id: I60d57fb728608e139a4540fabf1006fc2681d0a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io> |
|||||||||| | If loading the lldbbrige fails, we'll continue on to the next Qt Creator version if we find one. It makes more sense to report that we're about to load from a given version, so that any error messages from lldbbridge are output with that context in place. Change-Id: Icbab6f7d39333ce76d729fd0769cfdb44f05a2f0 Reviewed-by: Christian Stenger <christian.stenger@qt.io> |
||||||||||||| | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> |
|||||||||||||||||||||||||||||||||||||| | or from Xcode. A command line lldb that uses python3 fails to load the 'utils' module dependency when importing lldbbridge.py via the dSYM script debug_script.py. Add the directory where lldbbridge.py is as an additional import path to sys.path. This fixes the bridge to load in both CLI lldb and from within Xcode. Traceback (most recent call last): File "src/corelib/debug_script.py", line 92, in __lldb_init_module bridge = import_bridge(bridge_path, debugger, session_dict) File "src/corelib/debug_script.py", line 42, in import_bridge bridge = imp.load_source(MODULE_NAME, path) File "Versions/3.8/lib/python3.8/imp.py", line 171, in load_source module = _load(spec) File "<frozen importlib._bootstrap>", line 702, in _load File "<frozen importlib._bootstrap>", line 671, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 783, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "Qt Creator.app/Contents/Resources/debugger/lldbbridge.py", line 34, in <module> import utils ModuleNotFoundError: No module named 'utils' Amends 1b73c202ce907cd03864413f472bfeb5abf5151e Pick-to: 6.2 Change-Id: I521d7530e35ee9c51ae0418d2c532e58ec1952d0 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
||||||||| | This script was written for Python 2, which is deprecated now. Change-Id: I534c93922776254a4c822ac60c6fd77ca7cb9760 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: hjk <hjk@qt.io> |
| The script will look for the most recent Qt Creator version on the system, and pick up the LLDB summary providers from there, allowing pretty-printing of Qt types inside LLDB/Xcode. LLDB will detect the file when loading the dSYM, and inform the user that the file can be loaded to enable the formatters. The script can be loaded automatically by adding the following setting in ~/.lldbinit: settings set target.load-script-from-symbol-file true Which comes as a slight security risk, as other libraries might have scripts of their own. The alternative is to load the script directly from ~/.lldbinit: command script import "<path to debug script in dSYM>" With an optional target.load-script-from-symbol-file set to false, to silence the warning when loading the dSYM bundle. Change-Id: I01ba51dab725a8d0a58f1ad1749742443b639cc5 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |