[Lldb-commits] [lldb] 2914a4b - [lldb/Commands] Add `scripting template list` command with auto discovery
Author: Med Ismail Bennani
Date: 2024-07-25T00:12:06-07:00
New Revision: 2914a4b88837177d4a91a99525c1a3117242236d
URL:
https://github.com/llvm/llvm-project/commit/2914a4b88837177d4a91a99525c1a3117242236d
DIFF:
https://github.com/llvm/llvm-project/commit/2914a4b88837177d4a91a99525c1a3117242236d.diff
LOG: [lldb/Commands] Add `scripting template list` command with auto discovery
This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.
This was previously reviewed in #97273.
Signed-off-by: Med Ismail Bennani
Added:
lldb/include/lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h
lldb/source/Interpreter/Interfaces/CMakeLists.txt
lldb/source/Interpreter/Interfaces/ScriptedInterfaceUsages.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.h
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.h
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.h
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface/ScriptedThreadPlanPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface/ScriptedThreadPlanPythonInterface.h
Modified:
lldb/include/lldb/Core/PluginManager.h
lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
lldb/include/lldb/lldb-private-interfaces.h
lldb/source/Commands/CommandObjectScripting.cpp
lldb/source/Commands/Options.td
lldb/source/Core/PluginManager.cpp
lldb/source/Interpreter/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
Removed:
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface.cpp
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface.h
diff --git a/lldb/include/lldb/Core/PluginManager.h
b/lldb/include/lldb/Core/PluginManager.h
index 38a291d9f0afd..a23f834f471fb 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -10,6 +10,7 @@
#define LLDB_CORE_PLUGINMANAGER_H
#include "lldb/Core/Architecture.h"
+#include "lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h"
#include "lldb/Symbol/TypeSystem.h"
#include "lldb/Utility/CompletionRequest.h"
#include "lldb/Utility/FileSpec.h"
@@ -487,6 +488,25 @@ class PluginManager {
static LanguageSet GetAllTypeSystemSupportedLanguagesForExpressions();
+ // Scripted Interface
+ static bool RegisterPlugin(llvm::StringRef name, llvm::StringRef description,
+ ScriptedInterfaceCreateInstance create_callback,
+ lldb::ScriptLanguage language,
+ ScriptedInterfaceUsages usages);
+
+ static bool UnregisterPlugin(ScriptedInterfaceCreateInstance
create_callback);
+
+ static uint32_t GetNumScriptedInterfaces();
+
+ static llvm::StringRef GetScriptedInterfaceNameAtIndex(uint32_t idx);
+
+ static llvm::StringRef GetScriptedInterfaceDescriptionAtIndex(uint32_t idx);
+
+ static lldb::Script
[Lldb-commits] [lldb] [lldb][Linux] Parse, but don't store "comm" from /proc/stat file (PR #100387)
https://github.com/labath approved this pull request.
Yikes, I didn't realize this was new code. @feg208, we need to fix this soon.
I'm approving this because it strictly improves upon the current situation, but
I don't think it's not a complete fix. I think we can skip over the `comm`
field with a `rsplit(')')`. The rest could be parsed with scanf, as it's kinda
convenient -- even if old-fashioned. (A more modern approach would be either
with std::istringstream or some combination of StringRef::consumeInteger,
StringRef::ltrim, llvm::split and friends
https://github.com/llvm/llvm-project/pull/100387
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] f48c166 - [lldb][Linux] Parse, but don't store "comm" from /proc/stat file (#100387)
Author: David Spickett
Date: 2024-07-25T09:15:03+01:00
New Revision: f48c16631de07b47e0721b88bd8004e63897f29a
URL:
https://github.com/llvm/llvm-project/commit/f48c16631de07b47e0721b88bd8004e63897f29a
DIFF:
https://github.com/llvm/llvm-project/commit/f48c16631de07b47e0721b88bd8004e63897f29a.diff
LOG: [lldb][Linux] Parse, but don't store "comm" from /proc/stat file (#100387)
As reported in https://github.com/llvm/llvm-project/issues/89710, the %s
code used for `comm` could and probably does, overflow the buffer.
Likely we haven't seen it cause problems because the following data is
overwritten right afterwards.
Also scanf isn't a great choice here as this `comm` can include many
characters that might trip up %s.
We don't actually use `comm`, so parse but don't store it so we're not
overflowing anything.
Added:
Modified:
lldb/source/Host/linux/Host.cpp
Removed:
diff --git a/lldb/source/Host/linux/Host.cpp b/lldb/source/Host/linux/Host.cpp
index 5545f9ef4d70e..0bc736d90ea76 100644
--- a/lldb/source/Host/linux/Host.cpp
+++ b/lldb/source/Host/linux/Host.cpp
@@ -51,11 +51,9 @@ enum class ProcessState {
Zombie,
};
-constexpr int task_comm_len = 16;
-
struct StatFields {
::pid_t pid = LLDB_INVALID_PROCESS_ID;
- char comm[task_comm_len];
+ // comm
char state;
::pid_t ppid = LLDB_INVALID_PROCESS_ID;
::pid_t pgrp = LLDB_INVALID_PROCESS_ID;
@@ -100,8 +98,8 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
&ProcessInfo,
StatFields stat_fields;
if (sscanf(
Rest.data(),
- "%d %s %c %d %d %d %d %d %u %lu %lu %lu %lu %lu %lu %ld %ld %ld %ld",
- &stat_fields.pid, stat_fields.comm, &stat_fields.state,
+ "%d %*s %c %d %d %d %d %d %u %lu %lu %lu %lu %lu %lu %ld %ld %ld
%ld",
+ &stat_fields.pid, /* comm, */ &stat_fields.state,
&stat_fields.ppid, &stat_fields.pgrp, &stat_fields.session,
&stat_fields.tty_nr, &stat_fields.tpgid, &stat_fields.flags,
&stat_fields.minflt, &stat_fields.cminflt, &stat_fields.majflt,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Linux] Parse, but don't store "comm" from /proc/stat file (PR #100387)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/100387 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Correct format specifier for sscanf to prevent buffer overflow (NFC) (PR #94783)
DavidSpickett wrote: I have merged https://github.com/llvm/llvm-project/pull/100387 to fix this instead, because it needed some background knowledge to do correctly. But never the less, thank you @xgupta for making the effort to do this PR, it has uncovered some unsafe code that only recently went in. Which is a great result in itself! https://github.com/llvm/llvm-project/pull/94783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Correct format specifier for sscanf to prevent buffer overflow (NFC) (PR #94783)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/94783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c3a2efc - [lldb/Plugins] Fix build failure on windows following 2914a4b88837
Author: Med Ismail Bennani Date: 2024-07-25T01:19:23-07:00 New Revision: c3a2efceb53e1e3ab9b92e5bf6518ab51f4713a9 URL: https://github.com/llvm/llvm-project/commit/c3a2efceb53e1e3ab9b92e5bf6518ab51f4713a9 DIFF: https://github.com/llvm/llvm-project/commit/c3a2efceb53e1e3ab9b92e5bf6518ab51f4713a9.diff LOG: [lldb/Plugins] Fix build failure on windows following 2914a4b88837 This patch tries to fix the following build failure on windows: https://lab.llvm.org/buildbot/#/builders/141/builds/1083 This started happening following 2914a4b88837, and it seems to be caused by some special `#include` ordering for the lldb-python header on Windows. Signed-off-by: Med Ismail Bennani Added: Modified: lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.h lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.cpp lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface/ScriptedThreadPlanPythonInterface.h Removed: diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.h b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.h index 6d60f8b437d1c..001d49decb5b6 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.h +++ b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/OperatingSystemPythonInterface.h @@ -9,6 +9,14 @@ #ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_INTERFACES_OPERATINGSYSTEMPYTHONINTERFACE_H #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_INTERFACES_OPERATINGSYSTEMPYTHONINTERFACE_H +#if LLDB_ENABLE_PYTHON + +// clang-format off +// LLDB Python header must be included first +#include "../../lldb-python.h" +//clang-format on +#endif + #include "lldb/Host/Config.h" #include "lldb/Interpreter/Interfaces/OperatingSystemInterface.h" diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.cpp b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.cpp index 3586251bd4aac..19d2ee2c717d8 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.cpp +++ b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/ScriptedPlatformPythonInterface.cpp @@ -6,6 +6,15 @@ // //===--===// +#if LLDB_ENABLE_PYTHON + +// clang-format off +// LLDB Python header must be included first +#include "../../lldb-python.h" +//clang-format on + +#endif + #include "lldb/Core/PluginManager.h" #include "lldb/Host/Config.h" #include "lldb/Target/ExecutionContext.h" @@ -15,11 +24,6 @@ #if LLDB_ENABLE_PYTHON -// clang-format off -// LLDB Python header must be included first -#include "../../lldb-python.h" -//clang-format on - #include "../../SWIGPythonBridge.h" #include "../../ScriptInterpreterPythonImpl.h" #include "ScriptedPlatformPythonInterface.h" diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp index f4fba0848fe27..794c3e87ba97f 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp +++ b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp @@ -6,6 +6,14 @@ // //===--===// +#if LLDB_ENABLE_PYTHON + +// clang-format off +// LLDB Python header must be included first +#include "../../lldb-python.h" +//clang-format on +#endif + #include "lldb/Core/PluginManager.h" #include "lldb/Host/Config.h" #include "lldb/Target/Process.h" @@ -15,11 +23,6 @@ #if LLDB_ENABLE_PYTHON -// clang-format off -// LLDB Python header must be included first -#include "../../lldb-python.h" -//clang-format on - #include "../../SWIGPythonBridge.h" #include "../../ScriptInterpreterPythonImpl.h" #include "../ScriptedThreadPythonInterface.h" diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface/ScriptedThreadPlanPythonInterface.h b/lldb/source/Plugins/ScriptInterpreter/Python/Inte
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
@@ -18,7 +18,7 @@ def test_set_use_source_cache_false(self): self.set_use_source_cache_and_test(False) @skipIf(hostoslist=no_match(["windows"])) -@skipIf(oslist=["windows"]) # Fails on windows 11 +@expectedFailureAll(oslist=["windows"]) labath wrote: Looking at the tested functionality (and the surrounding code), this should probably be `hostoslist=windows` https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/labath commented: I'm somewhat surprised to see this many x86 xfails, given that we already have an arm64 windows bot, and that none of the tests I see here are very architecture-specific. I wonder if this could be due to how you've configured your build. @DavidSpickett, do you have any insight here? https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)
@@ -1,3 +1,5 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
labath wrote:
This is particularly concerning, given that this test just operates on static
binary data (expressed in yaml form). There should be nothing target-specific
here.
Maybe we could start by looking at what's making this test in particular fail?
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)
@@ -1,4 +1,5 @@
# UNSUPPORTED: system-windows
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
labath wrote:
This shouldn't be necessary given the UNSUPPORTED clause above.
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
labath wrote:
something like `system-windows && target-x86_64` ought to do it. However, like
I said in the other review, I think we ought to figure out why are these
failing for you.
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
# Make sure lldb can handle filenames with single quotes in them.
# RUN: %clang_host %p/Inputs/hello.c -g -o "%t-'pat"
labath wrote:
And this looks like you may have a different shell (one that handles quotes
differently) from the other windows devs/bots. Maybe we can figure out an
invocation that works with both? @DavidSpickett
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)
@@ -1,4 +1,5 @@
# UNSUPPORTED: system-windows
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
DavidSpickett wrote:
And this test I'm pretty sure is only failing due to cmd line syntax issues,
but no confirmation yet.
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev updated https://github.com/llvm/llvm-project/pull/99266 >From a54680b17e560460b67646622a674b574f2673b6 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Mon, 15 Jul 2024 22:52:40 +0200 Subject: [PATCH] [LLDB][test] Update Makefile.rules to support Windows host+Linux target These changes are aimed to support cross compilation build on Windows host for Linux target for API tests execution. They're not final: changes will follow for refactoring and adjustments to make all tests passing. Chocolatey make is recommended to use, since it is maintained better than GnuWin32 recommended here https://lldb.llvm.org/resources/build.html#codesigning (it was updated last time in 2010) and helps to avoid problems with building tests (for example, GnuWin32 doesn't support long paths and there are some other failures with building for Linux with it). This commit contains following changes: 1. Better SHELL detection for make to use on Windows host. 2. Paths are turned into POSIX-style since some tests and Unix utilities use them for manipulating files. It helps to avoid compiler/linker errors because of broken paths. 3. Compiler and linker flags are cleaned up to enable cross-compilation. --- .../Python/lldbsuite/test/make/Makefile.rules | 72 --- 1 file changed, 46 insertions(+), 26 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index be3ad684dd736..0a885451693a2 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -112,7 +112,7 @@ $(error "C compiler is not specified. Please run tests through lldb-dotest or li endif #-- -# Handle SDKROOT on Darwin +# Handle SDKROOT for the cross platform builds. #-- ifeq "$(OS)" "Darwin" @@ -120,6 +120,18 @@ ifeq "$(OS)" "Darwin" # We haven't otherwise set the SDKROOT, so set it now to macosx SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path) endif +SYSROOT_FLAGS := -isysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := +else +ifneq "$(SDKROOT)" "" +SYSROOT_FLAGS := --sysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := --gcc-toolchain="$(SDKROOT)/usr" +else +# Do not set up these options if SDKROOT was not specified. +# This is a regular build in that case (or Android). +SYSROOT_FLAGS := +GCC_TOOLCHAIN_FLAGS := +endif endif #-- @@ -210,20 +222,15 @@ endif DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 - -ifeq "$(OS)" "Darwin" - ifneq "$(SDKROOT)" "" - CFLAGS += -isysroot "$(SDKROOT)" - endif -endif +CFLAGS += $(SYSROOT_FLAGS) ifeq "$(OS)" "Darwin" CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) else CFLAGS += $(ARCHFLAG)$(ARCH) endif -CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include +CFLAGS += -I$(LLDB_BASE_DIR)/include -I$(LLDB_OBJ_ROOT)/include CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR) ifndef NO_TEST_COMMON_H @@ -234,9 +241,9 @@ CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) -isysroot "$(SDKROOT)" + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) @@ -378,11 +387,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TA
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -296,11 +313,13 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +#Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). dzhidzhoev wrote: Fixed https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -296,11 +313,13 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +#Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) - LDFLAGS += -pthread + LDFLAGS += -lpthread dzhidzhoev wrote: Fixed https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
dzhidzhoev wrote: > > > What exactly does it help with? Given that you're canonicalizing to a > > > forward slash, does that mean that some of the tools you use don't accept > > > backslashes (perhaps because they come from cygwin or the like)? > > > > > > As far as I understand, MinGW make, on which Chocolatey build is based, > > prefers \ or / slashes. > > I don't understand this sentence. Are you saying it prefers forward slashes > or backward slashes (or uniform slashes)? > > > Also, some include/library paths passed to clang seem to be > > ignored/incorrectly processed, when they have mixed path separators like > > C:\foo/bar > > This is interesting. I'm surprised that errors are coming from llvm tools, as > the llvm path libraries treat forward and backward slashes (on windows) as > equivalent at a very low level. Could you try to reduce this to to figure out > which specific slash in the command is causing the error? I want to make sure > we're not working around a bug here... When we were setting up cross-platform build and testing config, we had a multi-screen list of errors we had to solve. Also, we were unsure about the environment in which we would run this. Therefore we decided to bulk normalize all paths and some flags. But now I see that reverting this path separator-reverting change doesn't make much difference for us, so I revoked this part of the commit for now. https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev updated https://github.com/llvm/llvm-project/pull/99266 >From 1b2018229eb9d53a4f6cda1fb4f60229afa07367 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Mon, 15 Jul 2024 22:52:40 +0200 Subject: [PATCH] [LLDB][test] Update Makefile.rules to support Windows host+Linux target These changes are aimed to support cross compilation build on Windows host for Linux target for API tests execution. They're not final: changes will follow for refactoring and adjustments to make all tests passing. Chocolatey make is recommended to use, since it is maintained better than GnuWin32 recommended here https://lldb.llvm.org/resources/build.html#codesigning (it was updated last time in 2010) and helps to avoid problems with building tests (for example, GnuWin32 doesn't support long paths and there are some other failures with building for Linux with it). --- .../Python/lldbsuite/test/make/Makefile.rules | 72 --- 1 file changed, 46 insertions(+), 26 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index be3ad684dd736..0a885451693a2 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -112,7 +112,7 @@ $(error "C compiler is not specified. Please run tests through lldb-dotest or li endif #-- -# Handle SDKROOT on Darwin +# Handle SDKROOT for the cross platform builds. #-- ifeq "$(OS)" "Darwin" @@ -120,6 +120,18 @@ ifeq "$(OS)" "Darwin" # We haven't otherwise set the SDKROOT, so set it now to macosx SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path) endif +SYSROOT_FLAGS := -isysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := +else +ifneq "$(SDKROOT)" "" +SYSROOT_FLAGS := --sysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := --gcc-toolchain="$(SDKROOT)/usr" +else +# Do not set up these options if SDKROOT was not specified. +# This is a regular build in that case (or Android). +SYSROOT_FLAGS := +GCC_TOOLCHAIN_FLAGS := +endif endif #-- @@ -210,20 +222,15 @@ endif DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 - -ifeq "$(OS)" "Darwin" - ifneq "$(SDKROOT)" "" - CFLAGS += -isysroot "$(SDKROOT)" - endif -endif +CFLAGS += $(SYSROOT_FLAGS) ifeq "$(OS)" "Darwin" CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) else CFLAGS += $(ARCHFLAG)$(ARCH) endif -CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include +CFLAGS += -I$(LLDB_BASE_DIR)/include -I$(LLDB_OBJ_ROOT)/include CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR) ifndef NO_TEST_COMMON_H @@ -234,9 +241,9 @@ CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) -isysroot "$(SDKROOT)" + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) @@ -378,11 +387,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + # Otherwise no C++ library has been specified. Use stdc++ by default. + else +USE_LIBSTDCPP := 1 + endif +endif + ifeq (1,$(USE_LIBSTDCPP)) # Clang requires an extra flag: -stdlib=libstdc++ ifneq (,$(findstring clang,$(CC)))
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev edited https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
labath wrote: > When we were setting up cross-platform build and testing config, we had a > multi-screen list of errors we had to solve. Also, we were unsure about the > environment in which we would run this. Therefore we decided to bulk > normalize all paths and some flags. But now I see that reverting this path > separator-reverting change doesn't make much difference for us, so I revoked > this part of the commit for now. Got it. Thanks for clarifying. This makes the patch much easier to review. I think the main thing left to figure out here is the "default to libstdc++" part. https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix incorrect logical operator in 'if' condition check (NFC) (PR #94779)
https://github.com/xgupta edited https://github.com/llvm/llvm-project/pull/94779 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 2ba3fe7 - [lldb] Fix incorrect uses of logical operator in 'if' condition check (NFC) (#94779)
Author: Shivam Gupta
Date: 2024-07-25T16:59:39+05:30
New Revision: 2ba3fe7356f065757a2279f65e4ef5c8f1476293
URL:
https://github.com/llvm/llvm-project/commit/2ba3fe7356f065757a2279f65e4ef5c8f1476293
DIFF:
https://github.com/llvm/llvm-project/commit/2ba3fe7356f065757a2279f65e4ef5c8f1476293.diff
LOG: [lldb] Fix incorrect uses of logical operator in 'if' condition check
(NFC) (#94779)
The condition checking for missing class name, interpreter dictionary,
and script object incorrectly used logical AND (&&), which could never
be true to enter the 'if' block.
This commit uses separate if conditions for each class name, interpreter
dictionary, and script object.
Cought by cppcheck -
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h:89:11:
warning: Identical inner 'if' condition is always true.
[identicalInnerCondition]
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h:91:16:
warning: Identical inner 'if' condition is always true.
[identicalInnerCondition]
Fix #89195
-
Co-authored-by: Shivam Gupta
Added:
Modified:
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
Removed:
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
index e1a3156d10afd..2667f73516ba3 100644
---
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
+++
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
@@ -85,14 +85,15 @@ class ScriptedPythonInterface : virtual public
ScriptedInterface {
bool has_class_name = !class_name.empty();
bool has_interpreter_dict =
!(llvm::StringRef(m_interpreter.GetDictionaryName()).empty());
-if (!has_class_name && !has_interpreter_dict && !script_obj) {
- if (!has_class_name)
-return create_error("Missing script class name.");
- else if (!has_interpreter_dict)
-return create_error("Invalid script interpreter dictionary.");
- else
-return create_error("Missing scripting object.");
-}
+
+if (!has_class_name)
+ return create_error("Missing script class name.");
+
+if (!has_interpreter_dict)
+ return create_error("Invalid script interpreter dictionary.");
+
+if (!script_obj)
+ return create_error("Missing scripting object.");
Locker py_lock(&m_interpreter, Locker::AcquireLock | Locker::NoSTDIN,
Locker::FreeLock);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix incorrect logical operator in 'if' condition check (NFC) (PR #94779)
https://github.com/xgupta closed https://github.com/llvm/llvm-project/pull/94779 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix incorrect logical operator in 'if' condition check (NFC) (PR #94779)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `lldb-x86_64-debian` running on `lldb-x86_64-debian` while building `lldb` at step 6 "test". Full details are available at: https://lab.llvm.org/buildbot/#/builders/162/builds/2857 Here is the relevant piece of the build log for the reference: ``` Step 6 (test) failure: build (failure) ... PASS: lldb-api :: python_api/module_section/TestModuleAndSection.py (88 of 2633) PASS: lldb-api :: commands/expression/timeout/TestCallWithTimeout.py (89 of 2633) PASS: lldb-api :: commands/expression/persistent_result/TestPersistentResult.py (90 of 2633) PASS: lldb-api :: functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py (91 of 2633) PASS: lldb-api :: commands/gui/breakpoints/TestGuiBreakpoints.py (92 of 2633) PASS: lldb-api :: python_api/watchpoint/watchlocation/TestTargetWatchAddress.py (93 of 2633) PASS: lldb-api :: tools/lldb-dap/breakpoint/TestDAP_setBreakpoints.py (94 of 2633) PASS: lldb-api :: api/listeners/TestListener.py (95 of 2633) PASS: lldb-api :: functionalities/step-vrs-interrupt/TestStepVrsInterruptTimeout.py (96 of 2633) PASS: lldb-api :: tools/lldb-server/TestGdbRemote_vCont.py (97 of 2633) FAIL: lldb-api :: functionalities/postmortem/mach-core/TestMachCore.py (98 of 2633) TEST 'lldb-api :: functionalities/postmortem/mach-core/TestMachCore.py' FAILED Script: -- /usr/bin/python3 /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --env LLVM_LIBS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./lib --env LLVM_INCLUDE_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/include --env LLVM_TOOLS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./bin --arch x86_64 --build-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex --lldb-module-cache-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-clang/lldb-api --executable /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/lldb --compiler /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/clang --dsymutil /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/dsymutil --llvm-tools-dir /home/worker/2.0.1/lldb-x86_64-debian/build/./bin --lldb-obj-root /home/worker/2.0.1/lldb-x86_64-debian/build/tools/lldb --lldb-libs-dir /home/worker/2.0.1/lldb-x86_64-debian/build/./lib -t /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/postmortem/mach-core -p TestMachCore.py -- Exit Code: 1 Command Output (stdout): -- lldb version 20.0.0git (https://github.com/llvm/llvm-project.git revision 2ba3fe7356f065757a2279f65e4ef5c8f1476293) clang revision 2ba3fe7356f065757a2279f65e4ef5c8f1476293 llvm revision 2ba3fe7356f065757a2279f65e4ef5c8f1476293 Skipping the following test categories: ['libc++', 'dsym', 'gmodules', 'debugserver', 'objc'] -- Command Output (stderr): -- Change dir to: /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/postmortem/mach-core runCmd: settings clear -all output: runCmd: settings set symbols.enable-external-lookup false output: runCmd: settings set target.inherit-tcc true output: runCmd: settings set target.disable-aslr false output: runCmd: settings set target.detach-on-error false output: ``` https://github.com/llvm/llvm-project/pull/94779 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Revert "[lldb] Fix incorrect logical operator in 'if' condition check (NFC)" (PR #100561)
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/100561
Reverts llvm/llvm-project#94779
Due to bot failures: https://lab.llvm.org/buildbot/#/builders/18/builds/1371
>From b85152008f41e8136f5e21db875a63b464f8c10f Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 25 Jul 2024 13:16:55 +0100
Subject: [PATCH] =?UTF-8?q?Revert=20"[lldb]=20Fix=20incorrect=20uses=20of?=
=?UTF-8?q?=20logical=20operator=20in=20'if'=20condition=20check=E2=80=A6"?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 2ba3fe7356f065757a2279f65e4ef5c8f1476293.
---
.../Python/Interfaces/ScriptedPythonInterface.h | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
index 2667f73516ba3..e1a3156d10afd 100644
---
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
+++
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
@@ -85,15 +85,14 @@ class ScriptedPythonInterface : virtual public
ScriptedInterface {
bool has_class_name = !class_name.empty();
bool has_interpreter_dict =
!(llvm::StringRef(m_interpreter.GetDictionaryName()).empty());
-
-if (!has_class_name)
- return create_error("Missing script class name.");
-
-if (!has_interpreter_dict)
- return create_error("Invalid script interpreter dictionary.");
-
-if (!script_obj)
- return create_error("Missing scripting object.");
+if (!has_class_name && !has_interpreter_dict && !script_obj) {
+ if (!has_class_name)
+return create_error("Missing script class name.");
+ else if (!has_interpreter_dict)
+return create_error("Invalid script interpreter dictionary.");
+ else
+return create_error("Missing scripting object.");
+}
Locker py_lock(&m_interpreter, Locker::AcquireLock | Locker::NoSTDIN,
Locker::FreeLock);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] a466db2 - Revert "[lldb] Fix incorrect logical operator in 'if' condition check (NFC)" (#100561)
Author: David Spickett
Date: 2024-07-25T13:18:11+01:00
New Revision: a466db2b32cccfdbd8bbd27cfa2fb51651192075
URL:
https://github.com/llvm/llvm-project/commit/a466db2b32cccfdbd8bbd27cfa2fb51651192075
DIFF:
https://github.com/llvm/llvm-project/commit/a466db2b32cccfdbd8bbd27cfa2fb51651192075.diff
LOG: Revert "[lldb] Fix incorrect logical operator in 'if' condition check
(NFC)" (#100561)
Reverts llvm/llvm-project#94779
Due to bot failures:
https://lab.llvm.org/buildbot/#/builders/18/builds/1371
Added:
Modified:
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
Removed:
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
index 2667f73516ba3..e1a3156d10afd 100644
---
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
+++
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
@@ -85,15 +85,14 @@ class ScriptedPythonInterface : virtual public
ScriptedInterface {
bool has_class_name = !class_name.empty();
bool has_interpreter_dict =
!(llvm::StringRef(m_interpreter.GetDictionaryName()).empty());
-
-if (!has_class_name)
- return create_error("Missing script class name.");
-
-if (!has_interpreter_dict)
- return create_error("Invalid script interpreter dictionary.");
-
-if (!script_obj)
- return create_error("Missing scripting object.");
+if (!has_class_name && !has_interpreter_dict && !script_obj) {
+ if (!has_class_name)
+return create_error("Missing script class name.");
+ else if (!has_interpreter_dict)
+return create_error("Invalid script interpreter dictionary.");
+ else
+return create_error("Missing scripting object.");
+}
Locker py_lock(&m_interpreter, Locker::AcquireLock | Locker::NoSTDIN,
Locker::FreeLock);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Revert "[lldb] Fix incorrect logical operator in 'if' condition check (NFC)" (PR #100561)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/100561 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Revert "[lldb] Fix incorrect logical operator in 'if' condition check (NFC)" (PR #100561)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
Reverts llvm/llvm-project#94779
Due to bot failures: https://lab.llvm.org/buildbot/#/builders/18/builds/1371
---
Full diff: https://github.com/llvm/llvm-project/pull/100561.diff
1 Files Affected:
- (modified)
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
(+8-9)
``diff
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
index 2667f73516ba3..e1a3156d10afd 100644
---
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
+++
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
@@ -85,15 +85,14 @@ class ScriptedPythonInterface : virtual public
ScriptedInterface {
bool has_class_name = !class_name.empty();
bool has_interpreter_dict =
!(llvm::StringRef(m_interpreter.GetDictionaryName()).empty());
-
-if (!has_class_name)
- return create_error("Missing script class name.");
-
-if (!has_interpreter_dict)
- return create_error("Invalid script interpreter dictionary.");
-
-if (!script_obj)
- return create_error("Missing scripting object.");
+if (!has_class_name && !has_interpreter_dict && !script_obj) {
+ if (!has_class_name)
+return create_error("Missing script class name.");
+ else if (!has_interpreter_dict)
+return create_error("Invalid script interpreter dictionary.");
+ else
+return create_error("Missing scripting object.");
+}
Locker py_lock(&m_interpreter, Locker::AcquireLock | Locker::NoSTDIN,
Locker::FreeLock);
``
https://github.com/llvm/llvm-project/pull/100561
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix incorrect logical operator in 'if' condition check (NFC) (PR #94779)
DavidSpickett wrote: The code looks ok but as landed it turned `A && B && C` into `A || B || C`, despite that looking logical. @medismailben can you figure out the intent here, I'm assuming this was your code originally. https://github.com/llvm/llvm-project/pull/94779 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev updated https://github.com/llvm/llvm-project/pull/99266 >From 1d074bad4006134d164e96e21f9105b167212d53 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Mon, 15 Jul 2024 22:52:40 +0200 Subject: [PATCH] [LLDB][test] Update Makefile.rules to support Windows host+Linux target These changes are aimed to support cross compilation build on Windows host for Linux target for API tests execution. They're not final: changes will follow for refactoring and adjustments to make all tests passing. Chocolatey make is recommended to use, since it is maintained better than GnuWin32 recommended here https://lldb.llvm.org/resources/build.html#codesigning (it was updated last time in 2010) and helps to avoid problems with building tests (for example, GnuWin32 doesn't support long paths and there are some other failures with building for Linux with it). --- .../Python/lldbsuite/test/make/Makefile.rules | 72 --- 1 file changed, 46 insertions(+), 26 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index be3ad684dd736..8d54fc7f3321e 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -112,7 +112,7 @@ $(error "C compiler is not specified. Please run tests through lldb-dotest or li endif #-- -# Handle SDKROOT on Darwin +# Handle SDKROOT for the cross platform builds. #-- ifeq "$(OS)" "Darwin" @@ -120,6 +120,18 @@ ifeq "$(OS)" "Darwin" # We haven't otherwise set the SDKROOT, so set it now to macosx SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path) endif +SYSROOT_FLAGS := -isysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := +else +ifneq "$(SDKROOT)" "" +SYSROOT_FLAGS := --sysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := --gcc-toolchain="$(SDKROOT)/usr" +else +# Do not set up these options if SDKROOT was not specified. +# This is a regular build in that case (or Android). +SYSROOT_FLAGS := +GCC_TOOLCHAIN_FLAGS := +endif endif #-- @@ -210,20 +222,15 @@ endif DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 - -ifeq "$(OS)" "Darwin" - ifneq "$(SDKROOT)" "" - CFLAGS += -isysroot "$(SDKROOT)" - endif -endif +CFLAGS += $(SYSROOT_FLAGS) ifeq "$(OS)" "Darwin" CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) else CFLAGS += $(ARCHFLAG)$(ARCH) endif -CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include +CFLAGS += -I$(LLDB_BASE_DIR)/include -I$(LLDB_OBJ_ROOT)/include CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR) ifndef NO_TEST_COMMON_H @@ -234,9 +241,9 @@ CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) -isysroot "$(SDKROOT)" + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) @@ -378,11 +387,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + # Otherwise no C++ library has been specified. Use stdc++ by default. + else +USE_SYSTEM_STDLIB := 1 + endif +endif + ifeq (1,$(USE_LIBSTDCPP)) # Clang requires an extra flag: -stdlib=libstdc++ ifneq (,$(findstring clang,$(CC
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -80,9 +78,21 @@ endif # Also reset BUILDDIR value because "pwd" returns cygwin or msys path # which needs to be converted to windows path. #-- -ifeq "$(OS)" "Windows_NT" - SHELL = $(WINDIR)\system32\cmd.exe +path_wrapper = $(1) +ifeq "$(HOST_OS)" "Windows_NT" + # Windows 10 and later has the lower-case 'windir' env variable. + SHELL := $(or $(windir),$(WINDIR),C:\WINDOWS)\system32\cmd.exe BUILDDIR := $(shell echo %cd%) + + ifneq (,$(filter $(OS), Linux Android)) dzhidzhoev wrote: Removed this from the PR, together with path_wrapper thing. https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -418,11 +437,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ -lc++abi + # Otherwise no C++ library has been specified. Use stdc++ by default. + else +USE_LIBSTDCPP := 1 dzhidzhoev wrote: Changed it to USE_SYSTEM_STDLIB https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adjust the for loop condition to prevent unintended increments in ExpandRLE (NFC) (PR #94844)
https://github.com/xgupta updated
https://github.com/llvm/llvm-project/pull/94844
>From 5fe77213524d05581eca70b8a0d25e03fe8df793 Mon Sep 17 00:00:00 2001
From: Shivam Gupta
Date: Sat, 8 Jun 2024 11:52:08 +0530
Subject: [PATCH 1/2] [lldb] Adjust the for loop condition to prevent
unintended increments in ExpandRLE (NFC)
Address the issue reported by static analyser cppcheck regarding missing bounds
check for extra iterator increment in a loop.
This could lead to accessing out-of-bounds memory. To fix this we have adjusted
the loop conditions to not incrementing iterator c there..
Caught by cppcheck -
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1300:75:
warning: Missing bounds check for extra iterator increment in loop.
[StlMissingComparison]
Fix #91225
---
.../Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 8a47eed3d7cbe..81644d6248a83 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1297,7 +1297,7 @@ std::string GDBRemoteCommunication::ExpandRLE(std::string
packet) {
// Reserve enough byte for the most common case (no RLE used).
std::string decoded;
decoded.reserve(packet.size());
- for (std::string::const_iterator c = packet.begin(); c != packet.end(); ++c)
{
+ for (std::string::const_iterator c = packet.begin(); c != packet.end();) {
if (*c == '*') {
// '*' indicates RLE. Next character will give us the repeat count and
// previous character is what is to be repeated.
@@ -1316,6 +1316,7 @@ std::string GDBRemoteCommunication::ExpandRLE(std::string
packet) {
} else {
decoded.push_back(*c);
}
+c++;
}
return decoded;
}
>From b655f644e4744c98087ab0c8aee8bc38b3502c70 Mon Sep 17 00:00:00 2001
From: xgupta
Date: Thu, 25 Jul 2024 15:59:17 +0200
Subject: [PATCH 2/2] address review comment
---
.../Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 81644d6248a83..926310fa22328 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1298,7 +1298,7 @@ std::string GDBRemoteCommunication::ExpandRLE(std::string
packet) {
std::string decoded;
decoded.reserve(packet.size());
for (std::string::const_iterator c = packet.begin(); c != packet.end();) {
-if (*c == '*') {
+if (*c == '*' && std::next(c) != packet.end()) {
// '*' indicates RLE. Next character will give us the repeat count and
// previous character is what is to be repeated.
char char_to_repeat = decoded.back();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(SDKROOT)/usr/include/c++/v1 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++ +else +ifneq (,$(findstring clang,$(CC))) +# Force clang looking for the gcc's headers at specific rootfs folder. +CXXFLAGS += -stdlib=libstdc++ $(GCC_TOOLCHAIN_FLAGS) dzhidzhoev wrote: Agreed https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev updated https://github.com/llvm/llvm-project/pull/99266 >From 1d074bad4006134d164e96e21f9105b167212d53 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Mon, 15 Jul 2024 22:52:40 +0200 Subject: [PATCH 1/2] [LLDB][test] Update Makefile.rules to support Windows host+Linux target These changes are aimed to support cross compilation build on Windows host for Linux target for API tests execution. They're not final: changes will follow for refactoring and adjustments to make all tests passing. Chocolatey make is recommended to use, since it is maintained better than GnuWin32 recommended here https://lldb.llvm.org/resources/build.html#codesigning (it was updated last time in 2010) and helps to avoid problems with building tests (for example, GnuWin32 doesn't support long paths and there are some other failures with building for Linux with it). --- .../Python/lldbsuite/test/make/Makefile.rules | 72 --- 1 file changed, 46 insertions(+), 26 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index be3ad684dd736..8d54fc7f3321e 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -112,7 +112,7 @@ $(error "C compiler is not specified. Please run tests through lldb-dotest or li endif #-- -# Handle SDKROOT on Darwin +# Handle SDKROOT for the cross platform builds. #-- ifeq "$(OS)" "Darwin" @@ -120,6 +120,18 @@ ifeq "$(OS)" "Darwin" # We haven't otherwise set the SDKROOT, so set it now to macosx SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path) endif +SYSROOT_FLAGS := -isysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := +else +ifneq "$(SDKROOT)" "" +SYSROOT_FLAGS := --sysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := --gcc-toolchain="$(SDKROOT)/usr" +else +# Do not set up these options if SDKROOT was not specified. +# This is a regular build in that case (or Android). +SYSROOT_FLAGS := +GCC_TOOLCHAIN_FLAGS := +endif endif #-- @@ -210,20 +222,15 @@ endif DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 - -ifeq "$(OS)" "Darwin" - ifneq "$(SDKROOT)" "" - CFLAGS += -isysroot "$(SDKROOT)" - endif -endif +CFLAGS += $(SYSROOT_FLAGS) ifeq "$(OS)" "Darwin" CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) else CFLAGS += $(ARCHFLAG)$(ARCH) endif -CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include +CFLAGS += -I$(LLDB_BASE_DIR)/include -I$(LLDB_OBJ_ROOT)/include CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR) ifndef NO_TEST_COMMON_H @@ -234,9 +241,9 @@ CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) -isysroot "$(SDKROOT)" + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) @@ -378,11 +387,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + # Otherwise no C++ library has been specified. Use stdc++ by default. + else +USE_SYSTEM_STDLIB := 1 + endif +endif + ifeq (1,$(USE_LIBSTDCPP)) # Clang requires an extra flag: -stdlib=libstdc++ ifneq (,$(findstring clang,
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) dzhidzhoev wrote: It will allow adding extra flags to LDFLAGS via cmake (`-DLLDB_TEST_USER_ARGS="--env;LDFLAGS=-flag"`) without losing things automatically added to CFLAGS https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(SDKROOT)/usr/include/c++/v1 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++ +else +ifneq (,$(findstring clang,$(CC))) +# Force clang looking for the gcc's headers at specific rootfs folder. +CXXFLAGS += -stdlib=libstdc++ $(GCC_TOOLCHAIN_FLAGS) dzhidzhoev wrote: > This still forces the usage of libstdc++ on windows, right? Could we just > pass nothing here and let clang use its default? Actually, it's ignored on Windows. We have some problems without that line during cross-compiling, but I think it's due to missing $(GCC_TOOLCHAIN_FLAGS) content, not stdlib selection. https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev edited https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -378,11 +387,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + # Otherwise no C++ library has been specified. Use stdc++ by default. + else +USE_SYSTEM_STDLIB := 1 + endif +endif dzhidzhoev wrote: Thanks! https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -378,11 +387,28 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +# No C++ library has been specifieed. Use libstdc++ by default. +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit request was made, but we have paths to a custom libcxx, use + # them. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + # Otherwise no C++ library has been specified. Use stdc++ by default. + else +USE_SYSTEM_STDLIB := 1 + endif +endif + ifeq (1,$(USE_LIBSTDCPP)) # Clang requires an extra flag: -stdlib=libstdc++ ifneq (,$(findstring clang,$(CC))) - CXXFLAGS += -stdlib=libstdc++ - LDFLAGS += -stdlib=libstdc++ +# Force clang looking for the gcc's headers at specific rootfs folder. dzhidzhoev wrote: Fixed. https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev updated https://github.com/llvm/llvm-project/pull/99266 >From 0e513196fcf3cbcd13b7af941c4afc1ddf8be227 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Mon, 15 Jul 2024 22:52:40 +0200 Subject: [PATCH] [LLDB][test] Update Makefile.rules to support Windows host+Linux target These changes are aimed to support cross compilation build on Windows host for Linux target for API tests execution. They're not final: changes will follow for refactoring and adjustments to make all tests passing. Chocolatey make is recommended to use, since it is maintained better than GnuWin32 recommended here https://lldb.llvm.org/resources/build.html#codesigning (it was updated last time in 2010) and helps to avoid problems with building tests (for example, GnuWin32 doesn't support long paths and there are some other failures with building for Linux with it). Co-authored-by: Pavel Labath --- .../Python/lldbsuite/test/make/Makefile.rules | 70 --- 1 file changed, 44 insertions(+), 26 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index be3ad684dd736..8f30e1d292f70 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -112,7 +112,7 @@ $(error "C compiler is not specified. Please run tests through lldb-dotest or li endif #-- -# Handle SDKROOT on Darwin +# Handle SDKROOT for the cross platform builds. #-- ifeq "$(OS)" "Darwin" @@ -120,6 +120,18 @@ ifeq "$(OS)" "Darwin" # We haven't otherwise set the SDKROOT, so set it now to macosx SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path) endif +SYSROOT_FLAGS := -isysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := +else +ifneq "$(SDKROOT)" "" +SYSROOT_FLAGS := --sysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := --gcc-toolchain="$(SDKROOT)/usr" +else +# Do not set up these options if SDKROOT was not specified. +# This is a regular build in that case (or Android). +SYSROOT_FLAGS := +GCC_TOOLCHAIN_FLAGS := +endif endif #-- @@ -210,20 +222,15 @@ endif DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 - -ifeq "$(OS)" "Darwin" - ifneq "$(SDKROOT)" "" - CFLAGS += -isysroot "$(SDKROOT)" - endif -endif +CFLAGS += $(SYSROOT_FLAGS) ifeq "$(OS)" "Darwin" CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) else CFLAGS += $(ARCHFLAG)$(ARCH) endif -CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include +CFLAGS += -I$(LLDB_BASE_DIR)/include -I$(LLDB_OBJ_ROOT)/include CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR) ifndef NO_TEST_COMMON_H @@ -234,9 +241,9 @@ CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) -isysroot "$(SDKROOT)" + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) @@ -378,11 +387,26 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit C++ library request was made, but we have paths to a custom libcxx, use + # them. Otherwise, use the system library by default. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + else +USE_SYSTEM_STDLIB := 1 + endif +endif + ifeq (1,$(USE_LIBSTDCPP)) # Clang requires an extra flag: -stdlib=libstdc++ ifneq (,$(findstring clang,$(CC))) - CXXFLAGS += -stdlib=libstdc
[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/100577
I ran into this when LTO completely emptied two compile units, so they ended up
with the same hash (see #100375). Although, ideally, the compiler would try to
ensure we don't end up with a hash collision even in this case, guaranteeing
their absence is practically impossible. This patch ensures this situation does
not bring down lldb.
>From 357aecc085298fbad5a3be84f3508fa4314dadd0 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 25 Jul 2024 16:17:51 +0200
Subject: [PATCH] [lldb] Tolerate multiple compile units with the same DWO ID
I ran into this when LTO completely emptied two compile units, so they
ended up with the same hash (see #100375). Although, ideally, the
compiler would try to ensure we don't end up with a hash collision even
in this case, guaranteeing their absence is practically impossible. This
patch ensures this situation does not bring down lldb.
---
.../Plugins/SymbolFile/DWARF/DWARFUnit.cpp| 26 ++--
.../Plugins/SymbolFile/DWARF/DWARFUnit.h | 2 +-
.../SymbolFile/DWARF/x86/dwp-hash-collision.s | 142 ++
3 files changed, 156 insertions(+), 14 deletions(-)
create mode 100644 lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index 66a762bf9b685..0a52159d055bb 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() {
*m_dwo_id, m_first_die.GetOffset()));
return; // Can't fetch the compile unit from the dwo file.
}
- // If the skeleton compile unit gets its unit DIE parsed first, then this
- // will fill in the DWO file's back pointer to this skeleton compile unit.
- // If the DWO files get parsed on their own first the skeleton back link
- // can be done manually in DWARFUnit::GetSkeletonCompileUnit() which will
- // do a reverse lookup and cache the result.
- dwo_cu->SetSkeletonUnit(this);
+
+ // Link the DWO unit to this object, if it hasn't been linked already (this
+ // can happen when we have an index, and the DWO unit is parsed first).
+ if (!dwo_cu->LinkToSkeletonUnit(*this)) {
+SetDwoError(Status::createWithFormat(
+"multiple compile units with Dwo ID {0:x16}", *m_dwo_id));
+return;
+ }
DWARFBaseDIE dwo_cu_die = dwo_cu->GetUnitDIEOnly();
if (!dwo_cu_die.IsValid()) {
@@ -718,13 +720,11 @@ DWARFCompileUnit *DWARFUnit::GetSkeletonUnit() {
return llvm::dyn_cast_or_null(m_skeleton_unit);
}
-void DWARFUnit::SetSkeletonUnit(DWARFUnit *skeleton_unit) {
- // If someone is re-setting the skeleton compile unit backlink, make sure
- // it is setting it to a valid value when it wasn't valid, or if the
- // value in m_skeleton_unit was valid, it should be the same value.
- assert(skeleton_unit);
- assert(m_skeleton_unit == nullptr || m_skeleton_unit == skeleton_unit);
- m_skeleton_unit = skeleton_unit;
+bool DWARFUnit::LinkToSkeletonUnit(DWARFUnit &skeleton_unit) {
+ if (m_skeleton_unit && m_skeleton_unit != &skeleton_unit)
+return false;
+ m_skeleton_unit = &skeleton_unit;
+ return true;
}
bool DWARFUnit::Supports_DW_AT_APPLE_objc_complete_type() {
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
index 85c37971ced8e..209104fe3a054 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
@@ -170,7 +170,7 @@ class DWARFUnit : public UserID {
/// both cases correctly and avoids crashes.
DWARFCompileUnit *GetSkeletonUnit();
- void SetSkeletonUnit(DWARFUnit *skeleton_unit);
+ bool LinkToSkeletonUnit(DWARFUnit &skeleton_unit);
bool Supports_DW_AT_APPLE_objc_complete_type();
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
new file mode 100644
index 0..d626b4602ad58
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
@@ -0,0 +1,142 @@
+## Test that lldb handles (mainly, that it doesn't crash) the situation where
+## two skeleton compile units have the same DWO ID (and try to claim the same
+## split unit from the DWP file. This can sometimes happen when the compile
unit
+## is nearly empty (e.g. because LTO has optimized all of it away).
+
+# RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s --defsym MAIN=0 > %t
+# RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s > %t.dwp
+# RUN: %lldb %t -o "image lookup -t my_enum_type" \
+# RUN: -o "image dump separate-debug-info" -o exit | FileCheck %s
+
+## Check that we're able to access the type within the split unit (no matter
+## which skeleton unit it ends up associated with). Completely ignoring the
unit
+## might also be reasonable.
+# CHECK:
[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
I ran into this when LTO completely emptied two compile units, so they ended up
with the same hash (see #100375). Although, ideally, the compiler would
try to ensure we don't end up with a hash collision even in this case,
guaranteeing their absence is practically impossible. This patch ensures this
situation does not bring down lldb.
---
Full diff: https://github.com/llvm/llvm-project/pull/100577.diff
3 Files Affected:
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp (+13-13)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h (+1-1)
- (added) lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s (+142)
``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index 66a762bf9b685..0a52159d055bb 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() {
*m_dwo_id, m_first_die.GetOffset()));
return; // Can't fetch the compile unit from the dwo file.
}
- // If the skeleton compile unit gets its unit DIE parsed first, then this
- // will fill in the DWO file's back pointer to this skeleton compile unit.
- // If the DWO files get parsed on their own first the skeleton back link
- // can be done manually in DWARFUnit::GetSkeletonCompileUnit() which will
- // do a reverse lookup and cache the result.
- dwo_cu->SetSkeletonUnit(this);
+
+ // Link the DWO unit to this object, if it hasn't been linked already (this
+ // can happen when we have an index, and the DWO unit is parsed first).
+ if (!dwo_cu->LinkToSkeletonUnit(*this)) {
+SetDwoError(Status::createWithFormat(
+"multiple compile units with Dwo ID {0:x16}", *m_dwo_id));
+return;
+ }
DWARFBaseDIE dwo_cu_die = dwo_cu->GetUnitDIEOnly();
if (!dwo_cu_die.IsValid()) {
@@ -718,13 +720,11 @@ DWARFCompileUnit *DWARFUnit::GetSkeletonUnit() {
return llvm::dyn_cast_or_null(m_skeleton_unit);
}
-void DWARFUnit::SetSkeletonUnit(DWARFUnit *skeleton_unit) {
- // If someone is re-setting the skeleton compile unit backlink, make sure
- // it is setting it to a valid value when it wasn't valid, or if the
- // value in m_skeleton_unit was valid, it should be the same value.
- assert(skeleton_unit);
- assert(m_skeleton_unit == nullptr || m_skeleton_unit == skeleton_unit);
- m_skeleton_unit = skeleton_unit;
+bool DWARFUnit::LinkToSkeletonUnit(DWARFUnit &skeleton_unit) {
+ if (m_skeleton_unit && m_skeleton_unit != &skeleton_unit)
+return false;
+ m_skeleton_unit = &skeleton_unit;
+ return true;
}
bool DWARFUnit::Supports_DW_AT_APPLE_objc_complete_type() {
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
index 85c37971ced8e..209104fe3a054 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
@@ -170,7 +170,7 @@ class DWARFUnit : public UserID {
/// both cases correctly and avoids crashes.
DWARFCompileUnit *GetSkeletonUnit();
- void SetSkeletonUnit(DWARFUnit *skeleton_unit);
+ bool LinkToSkeletonUnit(DWARFUnit &skeleton_unit);
bool Supports_DW_AT_APPLE_objc_complete_type();
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
new file mode 100644
index 0..d626b4602ad58
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-hash-collision.s
@@ -0,0 +1,142 @@
+## Test that lldb handles (mainly, that it doesn't crash) the situation where
+## two skeleton compile units have the same DWO ID (and try to claim the same
+## split unit from the DWP file. This can sometimes happen when the compile
unit
+## is nearly empty (e.g. because LTO has optimized all of it away).
+
+# RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s --defsym MAIN=0 > %t
+# RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s > %t.dwp
+# RUN: %lldb %t -o "image lookup -t my_enum_type" \
+# RUN: -o "image dump separate-debug-info" -o exit | FileCheck %s
+
+## Check that we're able to access the type within the split unit (no matter
+## which skeleton unit it ends up associated with). Completely ignoring the
unit
+## might also be reasonable.
+# CHECK: image lookup -t my_enum_type
+# CHECK: 1 match found
+# CHECK: name = "my_enum_type", byte-size = 4, compiler_type = "enum
my_enum_type {
+# CHECK-NEXT: }"
+#
+## Check that we get some indication of the error.
+# CHECK: image dump separate-debug-info
+# CHECK: Dwo ID Err Dwo Path
+# CHECK: 0xdeadbeefbaadf00d E multiple compile units with Dwo ID
0xdeadbeefbaadf00d
+
+.set DWO_ID, 0xdeadbeefbaadf00d
+
+## The main file.
+.ifdef MAIN
+.section.debug_abbrev,"",@progbits
+.byte 1
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
https://github.com/dzhidzhoev updated
https://github.com/llvm/llvm-project/pull/95986
>From 11cabeefae5c7ecd44543eb8bfbba02430165a93 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Fri, 31 May 2024 21:39:56 +
Subject: [PATCH] [lldb][test] Support remote run of Shell tests
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake flags
to pass arguments for cross-compilation and remote running of both Shell&API
tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform
connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with remote
execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. Recommended compiler for that is Clang.
---
lldb/docs/resources/test.rst | 20 +++---
lldb/test/API/lit.cfg.py | 7 ++
lldb/test/API/lit.site.cfg.py.in | 3 +
lldb/test/CMakeLists.txt | 1 +
.../test/Shell/Settings/TestEchoCommands.test | 2 +
lldb/test/Shell/Target/target-label.test | 20 +++---
lldb/test/Shell/helper/toolchain.py | 67 ++-
lldb/test/Shell/lit.cfg.py| 9 ++-
lldb/test/Shell/lit.site.cfg.py.in| 7 +-
9 files changed, 112 insertions(+), 24 deletions(-)
diff --git a/lldb/docs/resources/test.rst b/lldb/docs/resources/test.rst
index 382e42bf22b10..23b6ab03559d4 100644
--- a/lldb/docs/resources/test.rst
+++ b/lldb/docs/resources/test.rst
@@ -592,15 +592,17 @@ test suite, but there are two things to have in mind:
multiple connections. For more information on how to setup remote debugging
see the Remote debugging page.
2. You must tell the test-suite how to connect to the remote system. This is
- achieved using the ``--platform-name``, ``--platform-url`` and
- ``--platform-working-dir`` parameters to ``dotest.py``. These parameters
- correspond to the platform select and platform connect LLDB commands. You
- will usually also need to specify the compiler and architecture for the
- remote system.
-
-Currently, running the remote test suite is supported only with ``dotest.py``
(or
-dosep.py with a single thread), but we expect this issue to be addressed in the
-near future.
+ achieved using the ``LLDB_TEST_PLATFORM_URL``,
``LLDB_TEST_PLATFORM_WORKING_DIR``
+ flags to cmake, and ``--platform-name`` parameter to ``dotest.py``.
+ These parameters correspond to the platform select and platform connect
+ LLDB commands. You will usually also need to specify the compiler and
+ architecture for the remote system.
+3. Remote Shell tests execution is currently supported only for Linux target
+ platform. It's triggered when ``LLDB_TEST_SYSROOT`` is provided for building
+ test sources. It can be disabled by setting
``LLDB_SHELL_TESTS_DISABLE_REMOTE=On``.
+ Shell tests are not guaranteed to pass against remote target if the compiler
+ being used is other than Clang.
+
Running tests in QEMU System Emulation Environment
``
diff --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 96520c7c82624..6a0a1b0a76675 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -303,6 +303,13 @@ def delete_module_cache(path):
# In particular, (1) is visited at the top of the file, since the script
# derives other information from it.
+if is_configured("lldb_platform_url"):
+dotest_cmd += ["--platform-url", config.lldb_platform_url]
+if is_configured("lldb_platform_working_dir"):
+dotest_cmd += ["--platform-working-dir", config.lldb_platform_working_dir]
+if is_configured("cmake_sysroot"):
+dotest_cmd += ["--sysroot", config.cmake_sysroot]
+
if is_configured("dotest_user_args_str"):
dotest_cmd.extend(config.dotest_user_args_str.split(";"))
diff --git a/lldb/test/API/lit.site.cfg.py.in b/lldb/test/API/lit.site.cfg.py.in
index 8b2d09ae41cd2..db3cd2971f347 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -24,6 +24,9 @@ config.lua_executable = "@Lua_EXECUTABLE@"
config.lua_test_entry = "TestLuaAPI.py"
config.dotest_common_args_str =
lit_config.substitute("@LLDB_TEST_COMMON_ARGS@")
config.dotest_user_args_str = lit_config.substitute("@LLDB_TEST_USER_ARGS@")
+config.lldb_platform_url = lit_config.substitute("@LLDB_TEST_PLATFORM_URL@")
+config.lldb_platform_working_dir =
lit_config.substitute("@LLDB_TEST_PLATFORM_WORKING_DIR@")
+config.cmake_sysroot = lit_config.substitute("@LLDB_TEST_SYSROOT@" or
"@DEFAULT_SYSROOT@")
config.lldb_enable_python = @LLDB_ENABLE_PYTHON@
config.dotest_lit_args_str = None
config.enabled_plugins = []
diff --git a/lldb/test/CMakeLists.txt b/lldb/test/CMakeLists.
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
https://github.com/dzhidzhoev edited https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
dzhidzhoev wrote: Updated: Added documentation lines. Added TEST_ prefix to cmake variables to indicate they doesn't affect lldb build (as proposed here https://discourse.llvm.org/t/rfc-lldb-support-remote-run-of-shell-tests/80072/5) Shell tests remote execution can now be disabled with `-DLLDB_SHELL_TESTS_DISABLE_REMOTE=On` (they should attempt to execute locally this way). To trigger remote execution, LLDB_TEST_PLATFORM_URL as well as LLDB_TEST_SYSROOT must be set. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (PR #100586)
https://github.com/dzhidzhoev created
https://github.com/llvm/llvm-project/pull/100586
It has been markad as XFAIL here de2ddc8f3146bd87152ea86b533541039541efe1, but
I haven't found the reason for that, and apparently, it passes against the
Linux target.
>From ea3f6bfd82e71b0c831fa438bb12f11955fc40ab Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Thu, 18 Jul 2024 20:30:38 +0200
Subject: [PATCH] [lldb][test] Mark TestAssertMessages.py as passing remotely
on Linux target.
It has been markad as XFAIL here de2ddc8f3146bd87152ea86b533541039541efe1,
but I haven't found an explanation why, and it passes against Linux target.
---
lldb/test/API/assert_messages_test/TestAssertMessages.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/test/API/assert_messages_test/TestAssertMessages.py
b/lldb/test/API/assert_messages_test/TestAssertMessages.py
index 3c54b9379d4c1..27d18e5ae99b9 100644
--- a/lldb/test/API/assert_messages_test/TestAssertMessages.py
+++ b/lldb/test/API/assert_messages_test/TestAssertMessages.py
@@ -23,7 +23,7 @@ def assert_expect_fails_with(self, cmd, expect_args,
expected_msg):
else:
self.fail("Initial expect should have raised AssertionError!")
-@expectedFailureAll(remote=True)
+@expectedFailureAll(oslist=no_match(["linux"]), remote=True)
def test_createTestTarget(self):
try:
self.createTestTarget("doesnt_exist")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (PR #100586)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Vladislav Dzhidzhoev (dzhidzhoev)
Changes
It has been markad as XFAIL here de2ddc8f3146bd87152ea86b533541039541efe1, but
I haven't found the reason for that, and apparently, it passes against the
Linux target.
---
Full diff: https://github.com/llvm/llvm-project/pull/100586.diff
1 Files Affected:
- (modified) lldb/test/API/assert_messages_test/TestAssertMessages.py (+1-1)
``diff
diff --git a/lldb/test/API/assert_messages_test/TestAssertMessages.py
b/lldb/test/API/assert_messages_test/TestAssertMessages.py
index 3c54b9379d4c1..27d18e5ae99b9 100644
--- a/lldb/test/API/assert_messages_test/TestAssertMessages.py
+++ b/lldb/test/API/assert_messages_test/TestAssertMessages.py
@@ -23,7 +23,7 @@ def assert_expect_fails_with(self, cmd, expect_args,
expected_msg):
else:
self.fail("Initial expect should have raised AssertionError!")
-@expectedFailureAll(remote=True)
+@expectedFailureAll(oslist=no_match(["linux"]), remote=True)
def test_createTestTarget(self):
try:
self.createTestTarget("doesnt_exist")
``
https://github.com/llvm/llvm-project/pull/100586
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (PR #100586)
https://github.com/dzhidzhoev converted_to_draft https://github.com/llvm/llvm-project/pull/100586 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (PR #100586)
https://github.com/dzhidzhoev ready_for_review https://github.com/llvm/llvm-project/pull/100586 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][x86_64][win] Set breakpoint condition on breakpoint instead of location in TestBreakpointConditions (PR #100487)
jimingham wrote: The only way that this could succeed on the breakpoint but fail on the location is that there are more than one locations and the one you are setting it on (the zeroth) is not the one that's hit. Since this test is "does a breakpoint condition on a location work" not "does this breakpoint always only produce one location" it might be better to just put the breakpoint on all the locations, and see if the one that is hit does work. https://github.com/llvm/llvm-project/pull/100487 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)
jimingham wrote: BTW, another reason I want to focus here on direction and not on explicitly stating "reverse continue" and "actual resume" is that a lot of "forward" motion in a debug session with reverse debugging capability is actually going to be going "forward" but using the "reverse" machinery, right? One pretty common workflow will be: 1) set a breakpoint and run backwards to hit it, 2) then run 'forwards' to figure out what happened there in the past - so for instance do a "forward next" to the next but still in the past source line 3) realize that you stepped over a function you wanted to look at so you step 'backwards' from one point in the past to another (back to the function call you stepped over) Most of the execution control logic should just know "forward" and "backwards", but then whether those are implemented by using the reverse debugging machinery or by allowing the program to run for realz will be know deeper in the execution control machinery - most likely governed by the thread plans. https://github.com/llvm/llvm-project/pull/99736 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev updated https://github.com/llvm/llvm-project/pull/99266 >From 4699a3b956b6684ca811baa50a13c6235f24be3f Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Mon, 15 Jul 2024 22:52:40 +0200 Subject: [PATCH] [LLDB][test] Update Makefile.rules to support Windows host+Linux target These changes are aimed to support cross compilation build on Windows host for Linux target for API tests execution. They're not final: changes will follow for refactoring and adjustments to make all tests passing. Chocolatey make is recommended to use, since it is maintained better than GnuWin32 recommended here https://lldb.llvm.org/resources/build.html#codesigning (it was updated last time in 2010) and helps to avoid problems with building tests (for example, GnuWin32 doesn't support long paths and there are some other failures with building for Linux with it). Co-authored-by: Pavel Labath --- .../Python/lldbsuite/test/make/Makefile.rules | 68 --- 1 file changed, 43 insertions(+), 25 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index be3ad684dd736..35dd93942c7d4 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -112,7 +112,7 @@ $(error "C compiler is not specified. Please run tests through lldb-dotest or li endif #-- -# Handle SDKROOT on Darwin +# Handle SDKROOT for the cross platform builds. #-- ifeq "$(OS)" "Darwin" @@ -120,6 +120,18 @@ ifeq "$(OS)" "Darwin" # We haven't otherwise set the SDKROOT, so set it now to macosx SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path) endif +SYSROOT_FLAGS := -isysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := +else +ifneq "$(SDKROOT)" "" +SYSROOT_FLAGS := --sysroot "$(SDKROOT)" +GCC_TOOLCHAIN_FLAGS := --gcc-toolchain="$(SDKROOT)/usr" +else +# Do not set up these options if SDKROOT was not specified. +# This is a regular build in that case (or Android). +SYSROOT_FLAGS := +GCC_TOOLCHAIN_FLAGS := +endif endif #-- @@ -210,20 +222,15 @@ endif DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 - -ifeq "$(OS)" "Darwin" - ifneq "$(SDKROOT)" "" - CFLAGS += -isysroot "$(SDKROOT)" - endif -endif +CFLAGS += $(SYSROOT_FLAGS) ifeq "$(OS)" "Darwin" CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) else CFLAGS += $(ARCHFLAG)$(ARCH) endif -CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include +CFLAGS += -I$(LLDB_BASE_DIR)/include -I$(LLDB_OBJ_ROOT)/include CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR) ifndef NO_TEST_COMMON_H @@ -234,9 +241,9 @@ CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) -isysroot "$(SDKROOT)" + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS) $(SYSROOT_FLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I, --isystem & etc). +LDFLAGS += $(CFLAGS) LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android Darwin)) ifneq (,$(filter YES,$(ENABLE_THREADS))) @@ -378,11 +387,26 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif endif +ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB))) + # If no explicit C++ library request was made, but we have paths to a custom libcxx, use + # them. Otherwise, use the system library by default. + ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),) +CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR) +ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" "" + CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR) +endif +LDFLAGS += -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++ + else +USE_SYSTEM_STDLIB := 1 + endif +endif + ifeq (1,$(USE_LIBSTDCPP)) # Clang requires an extra flag: -stdlib=libstdc++ ifneq (,$(findstring clang,$(CC))) - CXXFLAGS += -stdlib=libstdc
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(SDKROOT)/usr/include/c++/v1 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++ +else +ifneq (,$(findstring clang,$(CC))) +# Force clang looking for the gcc's headers at specific rootfs folder. +CXXFLAGS += -stdlib=libstdc++ $(GCC_TOOLCHAIN_FLAGS) dzhidzhoev wrote: > This still forces the usage of libstdc++ on windows, right? Could we just > pass nothing here and let clang use its default? Sorry, that was too early. We still need this flag. It is ignored for Windows target, but clang tries to pass -lc++ to linker in case of Linux target if -lstdc++ is not specified, and ld.lld fails to find it (since it's not present in my sysroot). https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)
https://github.com/dzhidzhoev edited https://github.com/llvm/llvm-project/pull/99266 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add constant value mode for RegisterLocation in UnwindPlans (PR #100624)
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/100624
This is useful for language runtimes that compute register values by inspecting
the state of the currently running process. Currently, there are no mechanisms
enabling these runtimes to set register values to arbitrary values.
The alternative considered would involve creating a dwarf expression that
produces an arbitrary integer (e.g. using OP_constu). However, the current data
structure for Rows is such that they do not own any memory associated with
dwarf expressions, which implies any such expression would need to have static
storage and therefore could not contain a runtime value.
Adding a new rule for constants leads to a simpler implementation. It's also
worth noting that this does not make the "Location" union any bigger, since it
already contains a pointer+size pair.
>From 223075d6f036537a7edec10b370f6d922135cb79 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Tue, 23 Jul 2024 13:30:40 -0700
Subject: [PATCH] [lldb] Add constant value mode for RegisterLocation in
UnwindPlans
This is useful for language runtimes that compute register values by inspecting
the state of the currently running process. Currently, there are no mechanisms
enabling these runtimes to set register values to arbitrary values.
The alternative considered would involve creating a dwarf expression that
produces an arbitrary integer (e.g. using OP_constu). However, the current data
structure for Rows is such that they do not own any memory associated with dwarf
expressions, which implies any such expression would need to have static storage
and therefore could not contain a runtime value.
Adding a new rule for constants leads to a simpler implementation. It's also
worth noting that this does not make the "Location" union any bigger, since it
already contains a pointer+size pair.
---
lldb/include/lldb/Symbol/UnwindPlan.h| 17 -
lldb/source/Symbol/UnwindPlan.cpp| 17 +
lldb/source/Target/RegisterContextUnwind.cpp | 9 +
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h
b/lldb/include/lldb/Symbol/UnwindPlan.h
index ebb0ec421da72..a9e8406608ff3 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -68,7 +68,8 @@ class UnwindPlan {
isAFAPlusOffset, // reg = AFA + offset
inOtherRegister, // reg = other reg
atDWARFExpression, // reg = deref(eval(dwarf_expr))
-isDWARFExpression // reg = eval(dwarf_expr)
+isDWARFExpression, // reg = eval(dwarf_expr)
+isConstant // reg = constant
};
RegisterLocation() : m_location() {}
@@ -105,6 +106,15 @@ class UnwindPlan {
bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
+ bool IsConstant() const { return m_type == isConstant; }
+
+ void SetIsConstant(uint64_t value) {
+m_type = isConstant;
+m_location.constant_value = value;
+ }
+
+ uint64_t GetConstant() const { return m_location.constant_value; }
+
void SetAtCFAPlusOffset(int32_t offset) {
m_type = atCFAPlusOffset;
m_location.offset = offset;
@@ -192,6 +202,8 @@ class UnwindPlan {
const uint8_t *opcodes;
uint16_t length;
} expr;
+// For m_type == isConstant
+uint64_t constant_value;
} m_location;
};
@@ -358,6 +370,9 @@ class UnwindPlan {
bool SetRegisterLocationToSame(uint32_t reg_num, bool must_replace);
+bool SetRegisterLocationToIsConstant(uint32_t reg_num, uint64_t constant,
+ bool can_replace);
+
// When this UnspecifiedRegistersAreUndefined mode is
// set, any register that is not specified by this Row will
// be described as Undefined.
diff --git a/lldb/source/Symbol/UnwindPlan.cpp
b/lldb/source/Symbol/UnwindPlan.cpp
index e258a4e3d82f2..fcd3154a01d82 100644
--- a/lldb/source/Symbol/UnwindPlan.cpp
+++ b/lldb/source/Symbol/UnwindPlan.cpp
@@ -46,6 +46,8 @@ operator==(const UnwindPlan::Row::RegisterLocation &rhs)
const {
return !memcmp(m_location.expr.opcodes, rhs.m_location.expr.opcodes,
m_location.expr.length);
break;
+case isConstant:
+ return m_location.constant_value == rhs.m_location.constant_value;
}
}
return false;
@@ -153,6 +155,9 @@ void UnwindPlan::Row::RegisterLocation::Dump(Stream &s,
if (m_type == atDWARFExpression)
s.PutChar(']');
} break;
+ case isConstant:
+s.Printf("=%x", m_location.offset);
+break;
}
}
@@ -351,6 +356,18 @@ bool UnwindPlan::Row::SetRegisterLocationToSame(uint32_t
reg_num,
return true;
}
+bool UnwindPlan::Row::SetRegisterLocationToIsConstant(uint32_t reg_num,
+ uint64_t constant,
+
[Lldb-commits] [lldb] [lldb] Add constant value mode for RegisterLocation in UnwindPlans (PR #100624)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Felipe de Azevedo Piovezan (felipepiovezan)
Changes
This is useful for language runtimes that compute register values by inspecting
the state of the currently running process. Currently, there are no mechanisms
enabling these runtimes to set register values to arbitrary values.
The alternative considered would involve creating a dwarf expression that
produces an arbitrary integer (e.g. using OP_constu). However, the current data
structure for Rows is such that they do not own any memory associated with
dwarf expressions, which implies any such expression would need to have static
storage and therefore could not contain a runtime value.
Adding a new rule for constants leads to a simpler implementation. It's also
worth noting that this does not make the "Location" union any bigger, since it
already contains a pointer+size pair.
---
Full diff: https://github.com/llvm/llvm-project/pull/100624.diff
3 Files Affected:
- (modified) lldb/include/lldb/Symbol/UnwindPlan.h (+16-1)
- (modified) lldb/source/Symbol/UnwindPlan.cpp (+17)
- (modified) lldb/source/Target/RegisterContextUnwind.cpp (+9)
``diff
diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h
b/lldb/include/lldb/Symbol/UnwindPlan.h
index ebb0ec421da72..a9e8406608ff3 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -68,7 +68,8 @@ class UnwindPlan {
isAFAPlusOffset, // reg = AFA + offset
inOtherRegister, // reg = other reg
atDWARFExpression, // reg = deref(eval(dwarf_expr))
-isDWARFExpression // reg = eval(dwarf_expr)
+isDWARFExpression, // reg = eval(dwarf_expr)
+isConstant // reg = constant
};
RegisterLocation() : m_location() {}
@@ -105,6 +106,15 @@ class UnwindPlan {
bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
+ bool IsConstant() const { return m_type == isConstant; }
+
+ void SetIsConstant(uint64_t value) {
+m_type = isConstant;
+m_location.constant_value = value;
+ }
+
+ uint64_t GetConstant() const { return m_location.constant_value; }
+
void SetAtCFAPlusOffset(int32_t offset) {
m_type = atCFAPlusOffset;
m_location.offset = offset;
@@ -192,6 +202,8 @@ class UnwindPlan {
const uint8_t *opcodes;
uint16_t length;
} expr;
+// For m_type == isConstant
+uint64_t constant_value;
} m_location;
};
@@ -358,6 +370,9 @@ class UnwindPlan {
bool SetRegisterLocationToSame(uint32_t reg_num, bool must_replace);
+bool SetRegisterLocationToIsConstant(uint32_t reg_num, uint64_t constant,
+ bool can_replace);
+
// When this UnspecifiedRegistersAreUndefined mode is
// set, any register that is not specified by this Row will
// be described as Undefined.
diff --git a/lldb/source/Symbol/UnwindPlan.cpp
b/lldb/source/Symbol/UnwindPlan.cpp
index e258a4e3d82f2..fcd3154a01d82 100644
--- a/lldb/source/Symbol/UnwindPlan.cpp
+++ b/lldb/source/Symbol/UnwindPlan.cpp
@@ -46,6 +46,8 @@ operator==(const UnwindPlan::Row::RegisterLocation &rhs)
const {
return !memcmp(m_location.expr.opcodes, rhs.m_location.expr.opcodes,
m_location.expr.length);
break;
+case isConstant:
+ return m_location.constant_value == rhs.m_location.constant_value;
}
}
return false;
@@ -153,6 +155,9 @@ void UnwindPlan::Row::RegisterLocation::Dump(Stream &s,
if (m_type == atDWARFExpression)
s.PutChar(']');
} break;
+ case isConstant:
+s.Printf("=%x", m_location.offset);
+break;
}
}
@@ -351,6 +356,18 @@ bool UnwindPlan::Row::SetRegisterLocationToSame(uint32_t
reg_num,
return true;
}
+bool UnwindPlan::Row::SetRegisterLocationToIsConstant(uint32_t reg_num,
+ uint64_t constant,
+ bool can_replace) {
+ if (!can_replace &&
+ m_register_locations.find(reg_num) != m_register_locations.end())
+return false;
+ RegisterLocation reg_loc;
+ reg_loc.SetIsConstant(constant);
+ m_register_locations[reg_num] = reg_loc;
+ return true;
+}
+
bool UnwindPlan::Row::operator==(const UnwindPlan::Row &rhs) const {
return m_offset == rhs.m_offset && m_cfa_value == rhs.m_cfa_value &&
m_afa_value == rhs.m_afa_value &&
diff --git a/lldb/source/Target/RegisterContextUnwind.cpp
b/lldb/source/Target/RegisterContextUnwind.cpp
index 95e8abd763d53..f74f1dc0e1b80 100644
--- a/lldb/source/Target/RegisterContextUnwind.cpp
+++ b/lldb/source/Target/RegisterContextUnwind.cpp
@@ -1694,6 +1694,15 @@ RegisterContextUnwind::SavedLocationForRegister(
return UnwindLLDB::RegisterSearchResult::eRegisterNotFound;
}
+ if (unwindplan_regloc.IsConstant()) {
+regloc.type = UnwindLLDB::RegisterLoc
[Lldb-commits] [lldb] [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (PR #100586)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/100586 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -75,6 +77,18 @@ lldb::SaveCoreStyle SBSaveCoreOptions::GetStyle() const {
return m_opaque_up->GetStyle();
}
+SBError SBSaveCoreOptions::SetProcess(lldb::SBProcess process) {
+ return m_opaque_up->SetProcess(process.GetSP());
+}
+
+SBError SBSaveCoreOptions::AddThread(lldb::SBThread thread) {
+ return m_opaque_up->AddThread(thread.get());
bulbazord wrote:
+1. Thread also has `enable_shared_from_this`, so that is an option as well.
https://github.com/llvm/llvm-project/pull/100443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 792b673 - [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (#100586)
Author: Vladislav Dzhidzhoev
Date: 2024-07-25T20:25:40+02:00
New Revision: 792b673d36a86ab9d45ed3b259a3fc7020826b76
URL:
https://github.com/llvm/llvm-project/commit/792b673d36a86ab9d45ed3b259a3fc7020826b76
DIFF:
https://github.com/llvm/llvm-project/commit/792b673d36a86ab9d45ed3b259a3fc7020826b76.diff
LOG: [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux
target. (#100586)
It has been markad as XFAIL here
de2ddc8f3146bd87152ea86b533541039541efe1, but I haven't found the reason
for that, and apparently, it passes against the Linux target.
Added:
Modified:
lldb/test/API/assert_messages_test/TestAssertMessages.py
Removed:
diff --git a/lldb/test/API/assert_messages_test/TestAssertMessages.py
b/lldb/test/API/assert_messages_test/TestAssertMessages.py
index 3c54b9379d4c1..27d18e5ae99b9 100644
--- a/lldb/test/API/assert_messages_test/TestAssertMessages.py
+++ b/lldb/test/API/assert_messages_test/TestAssertMessages.py
@@ -23,7 +23,7 @@ def assert_expect_fails_with(self, cmd, expect_args,
expected_msg):
else:
self.fail("Initial expect should have raised AssertionError!")
-@expectedFailureAll(remote=True)
+@expectedFailureAll(oslist=no_match(["linux"]), remote=True)
def test_createTestTarget(self):
try:
self.createTestTarget("doesnt_exist")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Mark TestAssertMessages.py as passing remotely on Linux target. (PR #100586)
https://github.com/dzhidzhoev closed https://github.com/llvm/llvm-project/pull/100586 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Remove decorator from XPASSes x86/Windows (PR #100628)
https://github.com/dzhidzhoev created https://github.com/llvm/llvm-project/pull/100628 This patch remove XFAIL decorator from tests which are passing on x86 Windows. Corresponding XFAILs for AArch64 were removed here 7daa9a9b40a22. >From 4d606e2b6991d382ee1ee688a86b2154cb70cb66 Mon Sep 17 00:00:00 2001 From: Vladislav Dzhidzhoev Date: Thu, 25 Jul 2024 12:17:25 +0200 Subject: [PATCH] [LLDB] Remove decorator from XPASSes x86/Windows This patch remove XFAIL decorator from tests which are passing on x86 Windows. Corresponding XFAILs for AArch64 were removed here 7daa9a9b40a22. --- .../TestClassTemplateNonTypeParameterPack.py | 3 --- .../TestClassTemplateTypeParameterPack.py | 3 --- 2 files changed, 6 deletions(-) diff --git a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py index 9e484e0132c83..730537da2fccf 100644 --- a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py @@ -5,9 +5,6 @@ class TestCaseClassTemplateNonTypeParameterPack(TestBase): -@expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] -) # Fails to read memory from target. @no_debug_info_test def test(self): self.build() diff --git a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py index 102c00dc603df..1ed643e6dd85c 100644 --- a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py @@ -5,9 +5,6 @@ class TestCaseClassTemplateTypeParameterPack(TestBase): -@expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] -) # Fails to read memory from target. @no_debug_info_test def test(self): self.build() ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Remove decorator from XPASSes x86/Windows (PR #100628)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Vladislav Dzhidzhoev (dzhidzhoev) Changes This patch remove XFAIL decorator from tests which are passing on x86 Windows. Corresponding XFAILs for AArch64 were removed here 7daa9a9b40a22. --- Full diff: https://github.com/llvm/llvm-project/pull/100628.diff 2 Files Affected: - (modified) lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py (-3) - (modified) lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py (-3) ``diff diff --git a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py index 9e484e0132c83..730537da2fccf 100644 --- a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py @@ -5,9 +5,6 @@ class TestCaseClassTemplateNonTypeParameterPack(TestBase): -@expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] -) # Fails to read memory from target. @no_debug_info_test def test(self): self.build() diff --git a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py index 102c00dc603df..1ed643e6dd85c 100644 --- a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py @@ -5,9 +5,6 @@ class TestCaseClassTemplateTypeParameterPack(TestBase): -@expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] -) # Fails to read memory from target. @no_debug_info_test def test(self): self.build() `` https://github.com/llvm/llvm-project/pull/100628 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Remove decorator from XPASSes x86/Windows (PR #100628)
https://github.com/dzhidzhoev edited https://github.com/llvm/llvm-project/pull/100628 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
@@ -18,7 +18,7 @@ def test_set_use_source_cache_false(self): self.set_use_source_cache_and_test(False) @skipIf(hostoslist=no_match(["windows"])) -@skipIf(oslist=["windows"]) # Fails on windows 11 +@expectedFailureAll(oslist=["windows"]) kendalharland wrote: Re: @DavidSpickett comment below. I am using the lldb-aarch64-windows builder as an example: - Run in cmd.exe - LLDB_TEST_COMPILER is the newly built clang-cl (top-level build uses host's MSVC) - `--skip-test-category=watchpoint` - LLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=ON - Python 3.9 My host system: - Win 11 Home Version 10.0.22631 Build 22631 - Dell XPS 8960 I haven't explicitly disabled hardware code breakpoints. What is the default and how do I do that? https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/kendalharland edited https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
@@ -18,7 +18,7 @@ def test_set_use_source_cache_false(self): self.set_use_source_cache_and_test(False) @skipIf(hostoslist=no_match(["windows"])) -@skipIf(oslist=["windows"]) # Fails on windows 11 +@expectedFailureAll(oslist=["windows"]) kendalharland wrote: To reproduce my local build if you have access to a machine and a clean checkout llvm/llvm-project: Run this in a developer command prompt in the root of the checkout: ``` set MSVC_INSTALL_DIR=C:\Program Files\Microsoft Visual Studio\2022\Community set "PATH=%MSVC_INSTALL_DIR%\DIA SDK\bin\amd64;%PATH%" cmake -G Ninja ^ -S llvm ^ -B build ^ -D Python3_EXECUTABLE="C:\Program Files\Python312\python.exe" ^ -D CMAKE_C_COMPILER="cl" ^ -D CMAKE_CXX_COMPILER="cl" ^ -D CMAKE_C_COMPILER_LAUNCHER=ccache ^ -D CMAKE_CXX_COMPILER_LAUNCHER=ccache ^ -D CMAKE_BUILD_TYPE="Release" ^ -D CMAKE_LINKER="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin\lld-link.exe" ^ -D LLVM_ENABLE_PROJECTS="clang;lldb;lld" ^ -D LLVM_HOST_TRIPLE="x86_64-unknown-windows-msvc" ^ -D LLVM_ENABLE_LLD="YES" ^ -D LLVM_ENABLE_LIBEDIT="NO" ^ -D LLVM_ENABLE_DIA_SDK="OFF" ^ -D LLDB_ENABLE_PYTHON=1 ^ -D LLDB_PYTHON_EXE_RELATIVE_PATH="python.exe" ^ -D LLDB_TEST_USER_ARGS=--skip-category=watchpoint ^ -D LLDB_TEST_COMPILER="clang-cl" ^ -D LLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=1 ^ -D LLDB_USE_LLDB_SERVER=1 ^ -D CMAKE_CXX_STANDARD=14 ``` https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/kendalharland edited https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/kendalharland edited https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c1d1a75 - [lldb/Plugins] Fix build failure on windows following 2914a4b88837
Author: Med Ismail Bennani Date: 2024-07-25T13:32:24-07:00 New Revision: c1d1a752cea105dba1aa999bc90feb5faa974bec URL: https://github.com/llvm/llvm-project/commit/c1d1a752cea105dba1aa999bc90feb5faa974bec DIFF: https://github.com/llvm/llvm-project/commit/c1d1a752cea105dba1aa999bc90feb5faa974bec.diff LOG: [lldb/Plugins] Fix build failure on windows following 2914a4b88837 This patch tries to fix the following build failure on windows: https://lab.llvm.org/buildbot/#/builders/141/builds/1083 This started happening following 2914a4b88837, and it seems to be caused by some special `#include` ordering for the lldb-python header on Windows. Signed-off-by: Med Ismail Bennani Added: Modified: lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPythonInterface.h lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h Removed: diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h index e1a3156d10afd..74b89a6f6a883 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h +++ b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h @@ -10,6 +10,12 @@ #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_INTERFACES_SCRIPTEDPYTHONINTERFACE_H #if LLDB_ENABLE_PYTHON +// clang-format off +// LLDB Python header must be included first +#include "../lldb-python.h" +//clang-format on +#endif + #include #include @@ -21,6 +27,8 @@ #include "lldb/Interpreter/Interfaces/ScriptedInterface.h" #include "lldb/Utility/DataBufferHeap.h" +#if LLDB_ENABLE_PYTHON + #include "../PythonDataObjects.h" #include "../SWIGPythonBridge.h" #include "../ScriptInterpreterPythonImpl.h" diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPythonInterface.h b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPythonInterface.h index 5676f7f1d6752..7724f9128c514 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPythonInterface.h +++ b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPythonInterface.h @@ -9,6 +9,13 @@ #ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_INTERFACES_SCRIPTEDTHREADPYTHONINTERFACE_H #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_INTERFACES_SCRIPTEDTHREADPYTHONINTERFACE_H +#if LLDB_ENABLE_PYTHON +// clang-format off +// LLDB Python header must be included first +#include "../lldb-python.h" +//clang-format on +#endif + #include "lldb/Host/Config.h" #if LLDB_ENABLE_PYTHON diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h b/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h index 88c1bb7e729e7..f5fb605c2bf3b 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h +++ b/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h @@ -48,12 +48,17 @@ #ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H -#include "lldb/Host/Config.h" - #if LLDB_ENABLE_PYTHON +// clang-format off // LLDB Python header must be included first #include "lldb-python.h" +//clang-format on +#endif + +#include "lldb/Host/Config.h" + +#if LLDB_ENABLE_PYTHON #include "lldb/Host/File.h" #include "lldb/Utility/StructuredData.h" diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h b/lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h index 3026b6113ae8f..efe173aeea8ea 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h +++ b/lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h @@ -9,15 +9,20 @@ #ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SWIGPYTHONBRIDGE_H #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SWIGPYTHONBRIDGE_H -#include -#include - -#include "lldb/Host/Config.h" - #if LLDB_ENABLE_PYTHON +// clang-format off // LLDB Python header must be included first #include "lldb-python.h" +//clang-format on +#endif + +#include "lldb/Host/Config.h" + +#include +#include + +#if LLDB_ENABLE_PYTHON #include "Plugins/ScriptInterpreter/Python/PythonDataObjects.h" #include "lldb/lldb-forward.h" diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h index 2e8301a85eb6c..c54530e2a5d8f 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPyth
[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)
@@ -0,0 +1,58 @@
+//===--- DirectToIndirectFCR.h - RISC-V specific pass
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#pragma once
+
+#include "lldb/lldb-types.h"
+
+#include "llvm/IR/Instructions.h"
+#include "llvm/Pass.h"
+
+namespace lldb_private {
+
+class ExecutionContext;
+
+// During the lldb expression execution lldb wraps a user expression, jittes
+// fabricated code and then puts it into the stack memory. Thus, if user tried
dlav-sc wrote:
Well, lldb generates its own code that wraps expression, something like:
```
#line 1 ""
#ifndef offsetof
#define offsetof(t, d) __builtin_offsetof(t, d)
#endif
#ifndef NULL
#define NULL (__null)
#endif
#ifndef Nil
#define Nil (__null)
#endif
#ifndef nil
#define nil (__null)
#endif
#ifndef YES
#define YES ((BOOL)1)
[Lldb-commits] [clang] [lldb] [HLSL] Implement intangible AST type (PR #97362)
@@ -8001,6 +8001,12 @@ NamedDecl *Sema::ActOnVariableDeclarator(
}
}
+ if (getLangOpts().HLSL) {
+if (R->isHLSLSpecificType() && !NewVD->isImplicit()) {
+ Diag(D.getBeginLoc(), diag::err_hlsl_intangible_type_cannot_be_declared);
llvm-beanz wrote:
`NewVD->isImplicit()` means the declaration is implicit and doesn't have any
source, that prevents us from being able to use these in `hlsl.h` or directly
in tests. I think that restriction may be more than we need.
https://github.com/llvm/llvm-project/pull/97362
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
https://github.com/slydiman created
https://github.com/llvm/llvm-project/pull/100659
We faced the issue running cross api tests in 8 threads. The executable is
installed to the target by the process `lldb-server platform`, but launched by
the another process `lldb-server gdbserver`. We got the error ETXTBSY on Linux
and ERROR_SHARING_VIOLATION on Windows. It seems the known issue and
ProcessLauncherPosixFork.cpp already contains the workaround, but it is not
enough. Updated the workaround with the total timeout 5 seconds and added the
same workaround to ProcessLauncherWindows.cpp too.
>From 6e24f75be4c779ed336a3894ac5312b0fc0e845c Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 01:48:35 +0400
Subject: [PATCH] [lldb] Improved lldb-server stability for remote launching
We faced the issue running cross api tests in 8 threads. The executable is
installed to the target by the process `lldb-server platform`, but launched by
the another process `lldb-server gdbserver`. We got the error ETXTBSY on Linux
and ERROR_SHARING_VIOLATION on Windows. It seems the known issue and
ProcessLauncherPosixFork.cpp already contains the workaround, but it is not
enough. Updated the workaround with the total timeout 5 seconds and added the
same workaround to ProcessLauncherWindows.cpp too.
---
.../Host/posix/ProcessLauncherPosixFork.cpp | 6 --
.../Host/windows/ProcessLauncherWindows.cpp | 20 +--
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 0a832ebad13a7..637c2846e6bb2 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -201,7 +201,7 @@ struct ForkLaunchInfo {
execve(info.argv[0], const_cast(info.argv), info.envp);
#if defined(__linux__)
- if (errno == ETXTBSY) {
+ for (int i = 0; i < 50; ++i) {
// On android M and earlier we can get this error because the adb daemon
// can hold a write handle on the executable even after it has finished
// uploading it. This state lasts only a short time and happens only when
@@ -210,7 +210,9 @@ struct ForkLaunchInfo {
// shell" command in the fork() child before it has had a chance to exec.)
// Since this state should clear up quickly, wait a while and then give it
// one more go.
-usleep(5);
+if (errno != ETXTBSY)
+ break;
+usleep(10);
execve(info.argv[0], const_cast(info.argv), info.envp);
}
#endif
diff --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index baa422c15cae2..143f20cb3f510 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -113,14 +113,30 @@ ProcessLauncherWindows::LaunchProcess(const
ProcessLaunchInfo &launch_info,
// command line is not empty, its contents may be modified by CreateProcessW.
WCHAR *pwcommandLine = wcommandLine.empty() ? nullptr : &wcommandLine[0];
- BOOL result = ::CreateProcessW(
+ BOOL result;
+ DWORD last_error = 0;
+ // This is the workaround for the error "The process cannot access the file
+ // because it is being used by another process". Note the executable file is
+ // installed to the target by the process `lldb-server platform`, but
launched
+ // by the process `lldb-server gdbserver`. Sometimes system may block the
file
+ // for some time after copying.
+ for (int i = 0; i < 50; ++i) {
+result = ::CreateProcessW(
wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
&startupinfo, &pi);
+if (!result) {
+ last_error = ::GetLastError();
+ if (last_error != ERROR_SHARING_VIOLATION)
+break;
+ ::Sleep(100);
+} else
+ break;
+ }
if (!result) {
// Call GetLastError before we make any other system calls.
-error.SetError(::GetLastError(), eErrorTypeWin32);
+error.SetError(last_error, eErrorTypeWin32);
// Note that error 50 ("The request is not supported") will occur if you
// try debug a 64-bit inferior from a 32-bit LLDB.
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dmitry Vasilyev (slydiman)
Changes
We faced the issue running cross api tests in 8 threads. The executable is
installed to the target by the process `lldb-server platform`, but launched by
the another process `lldb-server gdbserver`. We got the error ETXTBSY on Linux
and ERROR_SHARING_VIOLATION on Windows. It seems the known issue and
ProcessLauncherPosixFork.cpp already contains the workaround, but it is not
enough. Updated the workaround with the total timeout 5 seconds and added the
same workaround to ProcessLauncherWindows.cpp too.
---
Full diff: https://github.com/llvm/llvm-project/pull/100659.diff
2 Files Affected:
- (modified) lldb/source/Host/posix/ProcessLauncherPosixFork.cpp (+4-2)
- (modified) lldb/source/Host/windows/ProcessLauncherWindows.cpp (+18-2)
``diff
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 0a832ebad13a7..637c2846e6bb2 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -201,7 +201,7 @@ struct ForkLaunchInfo {
execve(info.argv[0], const_cast(info.argv), info.envp);
#if defined(__linux__)
- if (errno == ETXTBSY) {
+ for (int i = 0; i < 50; ++i) {
// On android M and earlier we can get this error because the adb daemon
// can hold a write handle on the executable even after it has finished
// uploading it. This state lasts only a short time and happens only when
@@ -210,7 +210,9 @@ struct ForkLaunchInfo {
// shell" command in the fork() child before it has had a chance to exec.)
// Since this state should clear up quickly, wait a while and then give it
// one more go.
-usleep(5);
+if (errno != ETXTBSY)
+ break;
+usleep(10);
execve(info.argv[0], const_cast(info.argv), info.envp);
}
#endif
diff --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index baa422c15cae2..143f20cb3f510 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -113,14 +113,30 @@ ProcessLauncherWindows::LaunchProcess(const
ProcessLaunchInfo &launch_info,
// command line is not empty, its contents may be modified by CreateProcessW.
WCHAR *pwcommandLine = wcommandLine.empty() ? nullptr : &wcommandLine[0];
- BOOL result = ::CreateProcessW(
+ BOOL result;
+ DWORD last_error = 0;
+ // This is the workaround for the error "The process cannot access the file
+ // because it is being used by another process". Note the executable file is
+ // installed to the target by the process `lldb-server platform`, but
launched
+ // by the process `lldb-server gdbserver`. Sometimes system may block the
file
+ // for some time after copying.
+ for (int i = 0; i < 50; ++i) {
+result = ::CreateProcessW(
wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
&startupinfo, &pi);
+if (!result) {
+ last_error = ::GetLastError();
+ if (last_error != ERROR_SHARING_VIOLATION)
+break;
+ ::Sleep(100);
+} else
+ break;
+ }
if (!result) {
// Call GetLastError before we make any other system calls.
-error.SetError(::GetLastError(), eErrorTypeWin32);
+error.SetError(last_error, eErrorTypeWin32);
// Note that error 50 ("The request is not supported") will occur if you
// try debug a 64-bit inferior from a 32-bit LLDB.
}
``
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff b1f263e4c2466a693609a3930f53b9887be67b5b
6e24f75be4c779ed336a3894ac5312b0fc0e845c --extensions cpp --
lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
lldb/source/Host/windows/ProcessLauncherWindows.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index 143f20cb3f..ee5f8fda1d 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -122,9 +122,9 @@ ProcessLauncherWindows::LaunchProcess(const
ProcessLaunchInfo &launch_info,
// for some time after copying.
for (int i = 0; i < 50; ++i) {
result = ::CreateProcessW(
- wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
- wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
- &startupinfo, &pi);
+wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
+wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
+&startupinfo, &pi);
if (!result) {
last_error = ::GetLastError();
if (last_error != ERROR_SHARING_VIOLATION)
``
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
@@ -201,7 +201,7 @@ struct ForkLaunchInfo {
execve(info.argv[0], const_cast(info.argv), info.envp);
#if defined(__linux__)
- if (errno == ETXTBSY) {
+ for (int i = 0; i < 50; ++i) {
bulbazord wrote:
Maybe it would be a good idea to make the timeout configurable?
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Remove python helper getCompilerBinary() (PR #100660)
https://github.com/kendalharland created
https://github.com/llvm/llvm-project/pull/100660
This causes a number of tests be `UNRESOLVED` on Windows if `getCompiler()` has
a space in the name, because `getCompilerBinary()` unconditionally splits on
whitespace and returns the first result, which might just be`"C:\Program"` if
using a compiler such as `clang-cl` `cl` from Visual studio's installation
directory.
>From c779fac5e7f5fbabaa79c98b31e20e7d567d1cd7 Mon Sep 17 00:00:00 2001
From: kendal
Date: Thu, 25 Jul 2024 14:59:25 -0700
Subject: [PATCH] [lldb][test] Remove getCompilerBinary() helper
---
lldb/packages/Python/lldbsuite/test/lldbplatformutil.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index e3c6fd1a99568..0bbe1db424630 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -266,16 +266,11 @@ def getCompiler():
return module.getCompiler()
-def getCompilerBinary():
-"""Returns the compiler binary the test suite is running with."""
-return getCompiler().split()[0]
-
-
def getCompilerVersion():
"""Returns a string that represents the compiler version.
Supports: llvm, clang.
"""
-compiler = getCompilerBinary()
+compiler = getCompiler()
version_output = subprocess.check_output([compiler, "--version"],
errors="replace")
m = re.search("version ([0-9.]+)", version_output)
if m:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Remove python helper getCompilerBinary() (PR #100660)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Kendal Harland (kendalharland)
Changes
This causes a number of tests be `UNRESOLVED` on Windows if `getCompiler()` has
a space in the name, because `getCompilerBinary()` unconditionally splits on
whitespace and returns the first result, which might just be`"C:\Program"` if
using a compiler such as `clang-cl` `cl` from Visual studio's installation
directory.
---
Full diff: https://github.com/llvm/llvm-project/pull/100660.diff
1 Files Affected:
- (modified) lldb/packages/Python/lldbsuite/test/lldbplatformutil.py (+1-6)
``diff
diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index e3c6fd1a99568..0bbe1db424630 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -266,16 +266,11 @@ def getCompiler():
return module.getCompiler()
-def getCompilerBinary():
-"""Returns the compiler binary the test suite is running with."""
-return getCompiler().split()[0]
-
-
def getCompilerVersion():
"""Returns a string that represents the compiler version.
Supports: llvm, clang.
"""
-compiler = getCompilerBinary()
+compiler = getCompiler()
version_output = subprocess.check_output([compiler, "--version"],
errors="replace")
m = re.search("version ([0-9.]+)", version_output)
if m:
``
https://github.com/llvm/llvm-project/pull/100660
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)
mysterymath wrote: The reland broke the Fuchsia Windows build with a similar error to the LLVM Windows bots, but I wasn't able to cleanly revert this commit without detailed knowledge of the contents. Could you revert this (preferentially) or fix forward? https://github.com/llvm/llvm-project/pull/97273 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
@@ -18,7 +18,7 @@ def test_set_use_source_cache_false(self): self.set_use_source_cache_and_test(False) @skipIf(hostoslist=no_match(["windows"])) -@skipIf(oslist=["windows"]) # Fails on windows 11 +@expectedFailureAll(oslist=["windows"]) kendalharland wrote: I made the following changes and I'm seeing far fewer failing tests now: - `LLDB_TEST_COMPILER` - leave this unset - `CMAKE_C_COMPILER="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin\clang-cl.exe"` - `CMAKE_CXX_COMPILER="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin\clang-cl.exe"` In short the compilers I was using caused many of the tests to fail. I am only seeing around 17 failures now in a clean checkout and will fix this one up. Thanks for the course correction! https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add constant value mode for RegisterLocation in UnwindPlans (PR #100624)
https://github.com/jasonmolenda edited https://github.com/llvm/llvm-project/pull/100624 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add constant value mode for RegisterLocation in UnwindPlans (PR #100624)
https://github.com/jasonmolenda approved this pull request. This looks good to me. One small nit on the Dump method. As a bit of background, this would be very unusual for a normal UnwindPlan that is reused for a function in many different contexts (different places on the stack during the program runtime). Felipe is dealing with the special case when the Swift LanguageRuntime creates an UnwindPlan that is used *once* in a given stack, and not saved in the UnwindTable for this Module. Felipe could have constructed a DWARF expression, where the register value was stored in memory, or a DWARF expression with a constant value, but then we'd need to add a `DataBufferSP` to the `RegisterLocation` to have ownership of this heap-allocated dwarf expression, in addition to hand-creating the DWARF expression bytecodes. It was a lot more straightforward to add this type of "this register is value x" for this one-shot UnwindPlan's that a LanguageRuntime can provide. https://github.com/llvm/llvm-project/pull/100624 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add constant value mode for RegisterLocation in UnwindPlans (PR #100624)
@@ -153,6 +155,9 @@ void UnwindPlan::Row::RegisterLocation::Dump(Stream &s,
if (m_type == atDWARFExpression)
s.PutChar(']');
} break;
+ case isConstant:
+s.Printf("=%x", m_location.offset);
jasonmolenda wrote:
Should the Printf be `("=0x%" PRIx64, m_location.constant_value)`? If you do
an unwind with one of these register locations in use, we should see this
output when the unwind engine shows the unwind rules being used for this
function.
https://github.com/llvm/llvm-project/pull/100624
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Remove python helper getCompilerBinary() (PR #100660)
https://github.com/kendalharland edited https://github.com/llvm/llvm-project/pull/100660 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)
@@ -158,7 +158,7 @@ class LLDB_API SBProcess {
lldb::SBError Destroy();
- lldb::SBError Continue();
+ lldb::SBError Continue(RunDirection direction = RunDirection::eRunForward);
clayborg wrote:
@jimingham: do you want all process control function to remain the same and
then add a direction control? Something like:
```
lldb::SBError SetRunDirection(RunDirection direction);
```
Jim is this what you are thinking?
And my API comments stand though, we can't change a pre-existing API. We can
add new overloads though
https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)
@@ -170,7 +170,7 @@ class DWARFUnit : public UserID {
/// both cases correctly and avoids crashes.
DWARFCompileUnit *GetSkeletonUnit();
- void SetSkeletonUnit(DWARFUnit *skeleton_unit);
+ bool LinkToSkeletonUnit(DWARFUnit &skeleton_unit);
clayborg wrote:
Is there a reason this was renamed?
https://github.com/llvm/llvm-project/pull/100577
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)
@@ -718,13 +720,11 @@ DWARFCompileUnit *DWARFUnit::GetSkeletonUnit() {
return llvm::dyn_cast_or_null(m_skeleton_unit);
}
-void DWARFUnit::SetSkeletonUnit(DWARFUnit *skeleton_unit) {
- // If someone is re-setting the skeleton compile unit backlink, make sure
- // it is setting it to a valid value when it wasn't valid, or if the
- // value in m_skeleton_unit was valid, it should be the same value.
- assert(skeleton_unit);
- assert(m_skeleton_unit == nullptr || m_skeleton_unit == skeleton_unit);
- m_skeleton_unit = skeleton_unit;
+bool DWARFUnit::LinkToSkeletonUnit(DWARFUnit &skeleton_unit) {
clayborg wrote:
No real reason to pass in a reference here since we want the pointer. The call
of this function is calling with `dwo_cu->LinkToSkeletonUnit(*this)`. Can we
change `DWARFUnit &skeleton_unit` back to `DWARFUnit *skeleton_unit`?
https://github.com/llvm/llvm-project/pull/100577
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Optimized lldb-server memory usage (PR #100666)
https://github.com/slydiman created
https://github.com/llvm/llvm-project/pull/100666
MAX_PATH is definitely larger than 6 bytes we are expecting for this message,
and could be rather large depending on the target OS (4K for some Linux OSs).
Since the buffer gets allocated on the stack we better be conservative and
allocate what we actually need.
>From 0e451f16b91bab2bc2cd1375eb02e4fe71998790 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 02:40:49 +0400
Subject: [PATCH] [lldb] Optimized lldb-server memory usage
MAX_PATH is definitely larger than 6 bytes we are expecting for this message,
and could be rather large depending on the target OS (4K for some Linux OSs).
Since the buffer gets allocated on the stack we better be conservative and
allocate what we actually need.
---
.../Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 187370eb36cae..b961c0e42469a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1145,7 +1145,8 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanWrite())
socket_pipe.CloseWriteFileDescriptor();
if (socket_pipe.CanRead()) {
-char port_cstr[PATH_MAX] = {0};
+// The port number may be "1024\0".."65535\0".
+char port_cstr[6] = {0};
port_cstr[0] = '\0';
size_t num_bytes = sizeof(port_cstr);
// Read port from pipe with 10 second timeout.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Optimized lldb-server memory usage (PR #100666)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dmitry Vasilyev (slydiman)
Changes
MAX_PATH is definitely larger than 6 bytes we are expecting for this message,
and could be rather large depending on the target OS (4K for some Linux OSs).
Since the buffer gets allocated on the stack we better be conservative and
allocate what we actually need.
---
Full diff: https://github.com/llvm/llvm-project/pull/100666.diff
1 Files Affected:
- (modified) lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
(+2-1)
``diff
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 187370eb36cae..b961c0e42469a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1145,7 +1145,8 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanWrite())
socket_pipe.CloseWriteFileDescriptor();
if (socket_pipe.CanRead()) {
-char port_cstr[PATH_MAX] = {0};
+// The port number may be "1024\0".."65535\0".
+char port_cstr[6] = {0};
port_cstr[0] = '\0';
size_t num_bytes = sizeof(port_cstr);
// Read port from pipe with 10 second timeout.
``
https://github.com/llvm/llvm-project/pull/100666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/100659
>From 21fd03faa1224d44bd132a0b53d66d896210a044 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 01:48:35 +0400
Subject: [PATCH] [lldb] Improved lldb-server stability for remote launching
We faced the issue running cross api tests in 8 threads. The executable is
installed to the target by the process `lldb-server platform`, but launched by
the another process `lldb-server gdbserver`. We got the error ETXTBSY on Linux
and ERROR_SHARING_VIOLATION on Windows. It seems the known issue and
ProcessLauncherPosixFork.cpp already contains the workaround, but it is not
enough. Updated the workaround with the total timeout 5 seconds and added the
same workaround to ProcessLauncherWindows.cpp too.
---
.../Host/posix/ProcessLauncherPosixFork.cpp | 6 +++--
.../Host/windows/ProcessLauncherWindows.cpp | 26 +++
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 0a832ebad13a7..637c2846e6bb2 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -201,7 +201,7 @@ struct ForkLaunchInfo {
execve(info.argv[0], const_cast(info.argv), info.envp);
#if defined(__linux__)
- if (errno == ETXTBSY) {
+ for (int i = 0; i < 50; ++i) {
// On android M and earlier we can get this error because the adb daemon
// can hold a write handle on the executable even after it has finished
// uploading it. This state lasts only a short time and happens only when
@@ -210,7 +210,9 @@ struct ForkLaunchInfo {
// shell" command in the fork() child before it has had a chance to exec.)
// Since this state should clear up quickly, wait a while and then give it
// one more go.
-usleep(5);
+if (errno != ETXTBSY)
+ break;
+usleep(10);
execve(info.argv[0], const_cast(info.argv), info.envp);
}
#endif
diff --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index baa422c15cae2..ee5f8fda1d492 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -113,14 +113,30 @@ ProcessLauncherWindows::LaunchProcess(const
ProcessLaunchInfo &launch_info,
// command line is not empty, its contents may be modified by CreateProcessW.
WCHAR *pwcommandLine = wcommandLine.empty() ? nullptr : &wcommandLine[0];
- BOOL result = ::CreateProcessW(
- wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
- wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
- &startupinfo, &pi);
+ BOOL result;
+ DWORD last_error = 0;
+ // This is the workaround for the error "The process cannot access the file
+ // because it is being used by another process". Note the executable file is
+ // installed to the target by the process `lldb-server platform`, but
launched
+ // by the process `lldb-server gdbserver`. Sometimes system may block the
file
+ // for some time after copying.
+ for (int i = 0; i < 50; ++i) {
+result = ::CreateProcessW(
+wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
+wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
+&startupinfo, &pi);
+if (!result) {
+ last_error = ::GetLastError();
+ if (last_error != ERROR_SHARING_VIOLATION)
+break;
+ ::Sleep(100);
+} else
+ break;
+ }
if (!result) {
// Call GetLastError before we make any other system calls.
-error.SetError(::GetLastError(), eErrorTypeWin32);
+error.SetError(last_error, eErrorTypeWin32);
// Note that error 50 ("The request is not supported") will occur if you
// try debug a 64-bit inferior from a 32-bit LLDB.
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)
@@ -0,0 +1,194 @@
+//===--- DirectToIndirectFCR.cpp - RISC-V specific pass
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/Function.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/IR/InstIterator.h"
+#include "llvm/IR/Instructions.h"
+#include "llvm/IR/LLVMContext.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IR/Value.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Support/Casting.h"
+#include "llvm/Transforms/Utils/BasicBlockUtils.h"
+
+#include "Plugins/Architecture/RISCV/DirectToIndirectFCR.h"
+
+#include "lldb/Core/Architecture.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Symbol/Symtab.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+
+#include
+
+using namespace llvm;
+using namespace lldb_private;
+
+namespace {
+std::string GetValueTypeStr(const llvm::Type *value_ty) {
+ assert(value_ty);
+ std::string str_type;
+ llvm::raw_string_ostream rso(str_type);
+ value_ty->print(rso);
+ return rso.str();
+}
+
+template void LogMessage(const char *msg, Args &&...args) {
+ Log *log = GetLog(LLDBLog::Expressions);
+ LLDB_LOG(log, msg, std::forward(args)...);
+}
+} // namespace
+
+bool DirectToIndirectFCR::canBeReplaced(const llvm::CallInst *ci) {
+ assert(ci);
+ auto *return_value_ty = ci->getType();
+ if (!(return_value_ty->isIntegerTy() || return_value_ty->isVoidTy())) {
dlav-sc wrote:
>I would have expected that, at the IR level, you could perform this kind of
>transformation for any return type.
As you've expected I really can apply this pass on functions with any
arguments' and return value's types. I just filter unsupported for some reasons
function calls.
As for doubles, I think that the problem is in the ABI or MCJIT, because the IR
is correct, while the resulting assembly from JIT compiler doesn't contain even
float instructions, needed to pass function arguments and get a return value.
My RISCV machine supports a float extension, so the assembly should contain
float instructions. Currently the result of such expressions is a trash, like:
```
(double) $1 = 3.3033229080945744E-319
```
so I've decided to remove function calls that takes double arguments or have
double return value.
As for pointers, as such no problems with them.
But if in function that takes char* argument pass a row c string, there will be
a SIGSEGV. Most interesting that if pass variable the function successfully
finished:
```
#include
void foo(const char *msg) {
printf("%s\n", msg);
}
int main() {
const char *msg = "msg";
foo(msg);
}
```
```
Process 302 stopped
* thread #1, name = 'pointer.x', stop reason = step over
frame #0: 0x000105cc pointer.x`main at pointer.cpp:9:6
6
7
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/kendalharland updated https://github.com/llvm/llvm-project/pull/100477 >From 5a32aac6f71c24bc111a1139b69a7568203dae69 Mon Sep 17 00:00:00 2001 From: kendal Date: Thu, 25 Jul 2024 15:26:38 -0700 Subject: [PATCH] [lldb][test][win][x86_64] Remove XFAIL from passing API tests --- .../API/functionalities/multiple-slides/TestMultipleSlides.py | 1 + .../API/functionalities/step-avoids-no-debug/TestStepNoDebug.py | 1 - .../TestClassTemplateNonTypeParameterPack.py| 2 +- .../TestClassTemplateTypeParameterPack.py | 2 +- lldb/test/API/python_api/thread/TestThreadAPI.py| 1 + 5 files changed, 4 insertions(+), 3 deletions(-) diff --git a/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py b/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py index 3d6b27fe68a1b..85fc4493d588b 100644 --- a/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py +++ b/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py @@ -12,6 +12,7 @@ class MultipleSlidesTestCase(TestBase): NO_DEBUG_INFO_TESTCASE = True +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) def test_mulitple_slides(self): """Test that a binary can be slid multiple times correctly.""" self.build() diff --git a/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py b/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py index a5ec87274a5ba..e80318b45dea4 100644 --- a/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py +++ b/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py @@ -2,7 +2,6 @@ Test thread step-in, step-over and step-out work with the "Avoid no debug" option. """ - import lldb from lldbsuite.test.decorators import * from lldbsuite.test.lldbtest import * diff --git a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py index 9e484e0132c83..1155f7ea44e7a 100644 --- a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py @@ -6,7 +6,7 @@ class TestCaseClassTemplateNonTypeParameterPack(TestBase): @expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] +oslist=["windows"], archs=["i[3-6]86"] ) # Fails to read memory from target. @no_debug_info_test def test(self): diff --git a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py index 102c00dc603df..efc609e843802 100644 --- a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py @@ -6,7 +6,7 @@ class TestCaseClassTemplateTypeParameterPack(TestBase): @expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] +oslist=["windows"], archs=["i[3-6]86"] ) # Fails to read memory from target. @no_debug_info_test def test(self): diff --git a/lldb/test/API/python_api/thread/TestThreadAPI.py b/lldb/test/API/python_api/thread/TestThreadAPI.py index 1898c6a2a9792..eeac804e921f4 100644 --- a/lldb/test/API/python_api/thread/TestThreadAPI.py +++ b/lldb/test/API/python_api/thread/TestThreadAPI.py @@ -52,6 +52,7 @@ def test_negative_indexing(self): self.build() self.validate_negative_indexing() +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) def test_StepInstruction(self): """Test that StepInstruction preserves the plan stack.""" self.build() ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
@@ -201,7 +201,7 @@ struct ForkLaunchInfo {
execve(info.argv[0], const_cast(info.argv), info.envp);
#if defined(__linux__)
- if (errno == ETXTBSY) {
+ for (int i = 0; i < 50; ++i) {
slydiman wrote:
I think it is redundant. Currently lldb-server contains a hardcoded timeout in
many places. Note the total timeout 10 seconds will cause the error "Sending
vRun packet failed". So 5 seconds is good enough for the stable connection and
do the trick on slow machines.
https://github.com/llvm/llvm-project/pull/100659
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)
https://github.com/dlav-sc edited https://github.com/llvm/llvm-project/pull/99336 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
https://github.com/kendalharland updated https://github.com/llvm/llvm-project/pull/100477 >From ac737efe9cb7d9fa690a6dfaa8ba7c6e006913c1 Mon Sep 17 00:00:00 2001 From: kendal Date: Thu, 25 Jul 2024 15:52:47 -0700 Subject: [PATCH] [lldb][test][win][x86_64] XFAIL already failing API tests These test are passing locally on win x86_64 using the following configuration (some options ellided for brevity) CMAKE_C_COMPILER clang-cl.exe CMAKE_CXX_COMPILER clang-cl.exe CMAKE_BUILD_TYPE Release CMAKE_LINKER lld-link.exe LLVM_HOST_TRIPLE="x86_64-unknown-windows-msvc" LLDB_TEST_USER_ARGS=--skip-category=watchpoint LLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=1 --- .../API/functionalities/multiple-slides/TestMultipleSlides.py | 1 + .../TestClassTemplateNonTypeParameterPack.py| 2 +- .../TestClassTemplateTypeParameterPack.py | 2 +- lldb/test/API/python_api/thread/TestThreadAPI.py| 1 + 4 files changed, 4 insertions(+), 2 deletions(-) diff --git a/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py b/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py index 3d6b27fe68a1b..85fc4493d588b 100644 --- a/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py +++ b/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py @@ -12,6 +12,7 @@ class MultipleSlidesTestCase(TestBase): NO_DEBUG_INFO_TESTCASE = True +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) def test_mulitple_slides(self): """Test that a binary can be slid multiple times correctly.""" self.build() diff --git a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py index 9e484e0132c83..1155f7ea44e7a 100644 --- a/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py @@ -6,7 +6,7 @@ class TestCaseClassTemplateNonTypeParameterPack(TestBase): @expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] +oslist=["windows"], archs=["i[3-6]86"] ) # Fails to read memory from target. @no_debug_info_test def test(self): diff --git a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py index 102c00dc603df..efc609e843802 100644 --- a/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py +++ b/lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py @@ -6,7 +6,7 @@ class TestCaseClassTemplateTypeParameterPack(TestBase): @expectedFailureAll( -oslist=["windows"], archs=["i[3-6]86", "x86_64"] +oslist=["windows"], archs=["i[3-6]86"] ) # Fails to read memory from target. @no_debug_info_test def test(self): diff --git a/lldb/test/API/python_api/thread/TestThreadAPI.py b/lldb/test/API/python_api/thread/TestThreadAPI.py index 1898c6a2a9792..eeac804e921f4 100644 --- a/lldb/test/API/python_api/thread/TestThreadAPI.py +++ b/lldb/test/API/python_api/thread/TestThreadAPI.py @@ -52,6 +52,7 @@ def test_negative_indexing(self): self.build() self.validate_negative_indexing() +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) def test_StepInstruction(self): """Test that StepInstruction preserves the plan stack.""" self.build() ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)
kendalharland wrote: Thanks for the assistance @labath and @DavidSpickett. After fixing my cmake configuration I'm actually seeing a few tests unexpectedly pass with different options: CMAKE_C_COMPILER clang-cl.exe CMAKE_CXX_COMPILER clang-cl.exe CMAKE_BUILD_TYPE Release CMAKE_LINKER lld-link.exe LLVM_HOST_TRIPLE x86_64-unknown-windows-msvc LLDB_TEST_USER_ARGS --skip-category=watchpoint LLDB_ENFORCE_STRICT_TEST_REQUIREMENTS 1 Updated in the latest commit https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)
medismailben wrote: > The reland broke the Fuchsia Windows build with a similar error to the LLVM > Windows bots, but I wasn't able to cleanly revert this commit without > detailed knowledge of the contents. Could you revert this (preferentially) or > fix forward? > > https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8741458989697976961/overview > > https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8741458989697976961/+/u/clang/build/stdout Looking at this. Thanks https://github.com/llvm/llvm-project/pull/97273 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test][win][x86_64] Remove XFAIL from XPASS'ing API tests (PR #100477)
https://github.com/kendalharland edited https://github.com/llvm/llvm-project/pull/100477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
