[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/100710
Depends on https://github.com/llvm/llvm-project/pull/100674
Currently, we treat VLAs declared as `int[]` and `int[0]` identically. I.e., we
create them as `IncompleteArrayType`s. However, the `DW_AT_count` for `int[0]`
*does* exist, and is retrievable without an execution context. This patch
decouples the notion of "has 0 elements" from "has no known `DW_AT_count`".
This aligns with how Clang represents `int[0]` in the AST (it treats it as a
`ConstantArrayType` of 0 size).
This issue was surfaced when adapting LLDB to
https://github.com/llvm/llvm-project/issues/93069. There, the
`__compressed_pair_padding` type has a `char[0]` member. If we previously got
the `__compressed_pair_padding` out of a module (where clang represents
`char[0]` as a `ConstantArrayType`), and try to merge the AST with one we got
from DWARF (where LLDB used to represent `char[0]` as an
`IncompleteArrayType`), the AST structural equivalence check fails, resulting
in silent ASTImporter failures. This manifested in a failure in
`TestNonModuleTypeSeparation.py`.
>From 9136653363bb7fc58e0b7f55a714d36d4613fe24 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 26 Jul 2024 01:19:02 +0100
Subject: [PATCH 1/2] [lldb][TypeSystemClang][NFC] Clean up
TypeSystemClang::GetBitSize
This patch does following NFC changes to TypeSystemClang::GetBitSize:
* Factor out the Objective-C logic into a helper function.
* We had a redundant check for `GetCompleteType` in the `RecordType`
case. We can remove that switch case entirely and rely on the
`default` case.
* Introduce a new case for `FunctionProto`. I don't see a good reason
for special-casing this in the `default` case.
* Introduce a new case for `IncompleteArray`.
The motivation for this is that there are a few issues around VLAs
(i.e., `Type::IncompleteArray`) whose fixes will be easier to reason
about after this refactor.
---
.../TypeSystem/Clang/TypeSystemClang.cpp | 114 +-
.../TypeSystem/Clang/TypeSystemClang.h| 3 +
2 files changed, 61 insertions(+), 56 deletions(-)
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index f70efe5ed57e4..3f7a6344542f4 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4725,67 +4725,69 @@ TypeSystemClang::GetFloatTypeSemantics(size_t
byte_size) {
return llvm::APFloatBase::Bogus();
}
+std::optional
+TypeSystemClang::GetObjCBitSize(QualType qual_type,
+ExecutionContextScope *exe_scope) {
+ assert(qual_type->isObjCObjectOrInterfaceType());
+ ExecutionContext exe_ctx(exe_scope);
+ Process *process = exe_ctx.GetProcessPtr();
+ if (process) {
+if (ObjCLanguageRuntime *objc_runtime =
+ObjCLanguageRuntime::Get(*process)) {
+ if (std::optional bit_size =
+ objc_runtime->GetTypeBitSize(GetType(qual_type)))
+return *bit_size;
+}
+ } else {
+static bool g_printed = false;
+if (!g_printed) {
+ StreamString s;
+ DumpTypeDescription(qual_type.getAsOpaquePtr(), s);
+
+ llvm::outs() << "warning: trying to determine the size of type ";
+ llvm::outs() << s.GetString() << "\n";
+ llvm::outs() << "without a valid ExecutionContext. this is not "
+ "reliable. please file a bug against LLDB.\n";
+ llvm::outs() << "backtrace:\n";
+ llvm::sys::PrintStackTrace(llvm::outs());
+ llvm::outs() << "\n";
+ g_printed = true;
+}
+ }
+
+ return getASTContext().getTypeSize(qual_type) +
+ getASTContext().getTypeSize(getASTContext().ObjCBuiltinClassTy);
+}
+
std::optional
TypeSystemClang::GetBitSize(lldb::opaque_compiler_type_t type,
ExecutionContextScope *exe_scope) {
- if (GetCompleteType(type)) {
-clang::QualType qual_type(GetCanonicalQualType(type));
-const clang::Type::TypeClass type_class = qual_type->getTypeClass();
-switch (type_class) {
-case clang::Type::Record:
- if (GetCompleteType(type))
-return getASTContext().getTypeSize(qual_type);
- else
-return std::nullopt;
- break;
+ if (!GetCompleteType(type))
+return std::nullopt;
-case clang::Type::ObjCInterface:
-case clang::Type::ObjCObject: {
- ExecutionContext exe_ctx(exe_scope);
- Process *process = exe_ctx.GetProcessPtr();
- if (process) {
-if (ObjCLanguageRuntime *objc_runtime =
-ObjCLanguageRuntime::Get(*process)) {
- if (std::optional bit_size =
- objc_runtime->GetTypeBitSize(GetType(qual_type)))
-return *bit_size;
-}
- } else {
-static bool g_printed = false;
-if (!g_printed) {
- StreamString s;
- DumpTypeDescription(type, s);
-
-
[Lldb-commits] [lldb] [lldb] Optimized lldb-server memory usage (PR #100666)
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/100666
>From 0e451f16b91bab2bc2cd1375eb02e4fe71998790 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 02:40:49 +0400
Subject: [PATCH 1/2] [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.
>From 4562af94a7417575fec100e5bbe745b21870e6fc Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 11:55:08 +0400
Subject: [PATCH 2/2] Removed the redundant line.
---
.../source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index b961c0e42469a..07aa8209ca4ba 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1147,7 +1147,6 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanRead()) {
// 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.
error = socket_pipe.ReadWithTimeout(
___
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)
@@ -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';
slydiman wrote:
Updated. Thanks.
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] Remove decorator from XPASSes x86/Windows (PR #100628)
https://github.com/DavidSpickett approved this pull request. LGTM. 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 python helper getCompilerBinary() (PR #100660)
https://github.com/DavidSpickett 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] Remove python helper getCompilerBinary() (PR #100660)
@@ -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") DavidSpickett wrote: Might as well put `getCompiler()` directly in this line, no local variable needed. 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] Remove python helper getCompilerBinary() (PR #100660)
DavidSpickett wrote: Seems fine to me, but there is a use of it in `lldb/packages/Python/lldbsuite/test/lldbtest.py` that should also be removed. 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][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) labath wrote: Okay, sounds good. 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] Remove python helper getCompilerBinary() (PR #100660)
DavidSpickett wrote: And the CI failure is one of our old friends: ``` Timed Out Tests (1): lldb-api :: functionalities/fork/concurrent_vfork/TestConcurrentVFork.py ``` That you can safely ignore. 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][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) labath wrote: Okay, but that is a clang configuration thing (`CLANG_DEFAULT_CXX_STDLIB` cmake option), right? Can't you set it to the actual c++ library that you intend to use instead of overriding it here? Or use a clang wrapper or a [configuration file](https://clang.llvm.org/docs/UsersManual.html#configuration-files) to override it externally? (FWIW, that's what we do internally to adapt the test suite to our (strange) internal infrastructure) It's nice (maybe) that `-lstdc++` is ignored on windows, but I still this this is the wrong thing to do. `libstdc++` is definitely not the system default everywhere. 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] IRMemoryMap zero address mapping fix (PR #99045)
dlav-sc wrote: > I put up a PR that avoids a memory region starting at address 0, and also > clarifies the documentation of the qMemoryRegionInfo packet to state that > permissions: are required for all memory regions that are accessible by the > inferior process. A memory region with no `permissions:` key means that it is > not an accessible region of memory. I put this PR up at #100288 @dlav-sc what > do you think? I know you've moved past this issue by implementing > memory-allocation and fixing your qMemoryRegionInfo packet response, but I > wanted to get a final fix before we all walk away from this PR. I've checked your patch on my machine and it works, so looks good to me. >I've merged https://github.com/llvm/llvm-project/pull/100288 I think we >should close this PR. Yep, lets close this PR. https://github.com/llvm/llvm-project/pull/99045 ___ 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] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
DavidSpickett wrote: > I'd show a full test log but for whatever reason, it's not being verbose > despite being asked to, working on that. I've fixed this, you can get a full test list by downloading the log file e.g. https://lab.llvm.org/buildbot/#/builders/141/builds/1139/steps/6/logs/stdio. 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] 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) {
labath wrote:
A reference implies (and documents) non-nullness of the argument. This removes
the need for the `assert(skeleton_unit);` inside the function and makes it
clear to the caller that it must pass a valid object. I don't strongly about
it, but I think that's worth an extra `*` at the call site.
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][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
@@ -52,6 +52,7 @@ def test_negative_indexing(self): self.build() self.validate_negative_indexing() +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) DavidSpickett wrote: I recently updated this for Windows on Arm https://github.com/llvm/llvm-project/commit/3e06392c7db0eacfca94a176d430d9988b3ffbd6, that's where that regex came from. We need to know if it's a cosmetic difference or whether it's stopped at a completely different place. Running the test with `lldb-dotest` and the `-t` flag will hopefully show you what it was doing. 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] 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);
labath wrote:
It just seemed to me like `Set` does not capture very well the new semantics of
the function (a typical setter function just sets the corresponding field and
does not second-guess the callers intentions). A nice side benefit is that we
can be sure to catch all callers of the api to make sure they're not silently
ignoring the result.
I can revert it if you feel strongly about it.
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] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)
@@ -746,27 +746,18 @@ Status Scalar::SetValueFromData(const DataExtractor &data,
bool Scalar::SignExtend(uint32_t sign_bit_pos) {
const uint32_t max_bit_pos = GetByteSize() * 8;
- if (sign_bit_pos < max_bit_pos) {
-switch (m_type) {
-case Scalar::e_void:
-case Scalar::e_float:
- return false;
+ assert(sign_bit_pos <= max_bit_pos);
xgupta wrote:
Yes, I have realized this now, asserts are discoursed in the LLDB debugger and
it mentions in docs -
https://lldb.llvm.org/resources/contributing.html#error-handling-and-use-of-assertions-in-lldb.
https://github.com/llvm/llvm-project/pull/95678
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)
https://github.com/xgupta updated
https://github.com/llvm/llvm-project/pull/95678
>From ef5b9cefb408ca3a721c95d8f6702abba77a602b Mon Sep 17 00:00:00 2001
From: Shivam Gupta
Date: Sun, 16 Jun 2024 00:21:51 +0530
Subject: [PATCH 1/4] [LLDB] Add an assert to verify sign_bit_pos is within the
valid range
---
lldb/source/Utility/Scalar.cpp | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index c680101aa9efa..6e2f1ca4c1613 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -745,26 +745,25 @@ Status Scalar::SetValueFromData(const DataExtractor &data,
bool Scalar::SignExtend(uint32_t sign_bit_pos) {
const uint32_t max_bit_pos = GetByteSize() * 8;
+ assert(sign_bit_pos < max_bit_pos);
- if (sign_bit_pos < max_bit_pos) {
-switch (m_type) {
-case Scalar::e_void:
-case Scalar::e_float:
- return false;
+ switch (m_type) {
+ case Scalar::e_void:
+ case Scalar::e_float:
+return false;
-case Scalar::e_int:
- if (sign_bit_pos < (max_bit_pos - 1)) {
-llvm::APInt sign_bit = llvm::APInt::getSignMask(sign_bit_pos + 1);
-llvm::APInt bitwize_and = m_integer & sign_bit;
-if (bitwize_and.getBoolValue()) {
- llvm::APInt mask =
- ~(sign_bit) + llvm::APInt(m_integer.getBitWidth(), 1);
- m_integer |= APSInt(std::move(mask), m_integer.isUnsigned());
-}
-return true;
+ case Scalar::e_int:
+if (sign_bit_pos < (max_bit_pos - 1)) {
+ llvm::APInt sign_bit = llvm::APInt::getSignMask(sign_bit_pos + 1);
+ llvm::APInt bitwize_and = m_integer & sign_bit;
+ if (bitwize_and.getBoolValue()) {
+llvm::APInt mask =
+~(sign_bit) + llvm::APInt(m_integer.getBitWidth(), 1);
+m_integer |= APSInt(std::move(mask), m_integer.isUnsigned());
}
- break;
+ return true;
}
+break;
}
return false;
}
>From 98a183742e3dc6393aa55000fff1931263ff165a Mon Sep 17 00:00:00 2001
From: Shivam Gupta
Date: Wed, 19 Jun 2024 13:57:55 +0530
Subject: [PATCH 2/4] address review suggestion
---
lldb/source/Utility/Scalar.cpp | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 6e2f1ca4c1613..496f402a74114 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -747,25 +747,17 @@ bool Scalar::SignExtend(uint32_t sign_bit_pos) {
const uint32_t max_bit_pos = GetByteSize() * 8;
assert(sign_bit_pos < max_bit_pos);
- switch (m_type) {
- case Scalar::e_void:
- case Scalar::e_float:
+ if (m_type != Scalar::e_int || sign_bit_pos >= (max_bit_pos - 1)) {
return false;
+ }
- case Scalar::e_int:
-if (sign_bit_pos < (max_bit_pos - 1)) {
- llvm::APInt sign_bit = llvm::APInt::getSignMask(sign_bit_pos + 1);
- llvm::APInt bitwize_and = m_integer & sign_bit;
- if (bitwize_and.getBoolValue()) {
-llvm::APInt mask =
-~(sign_bit) + llvm::APInt(m_integer.getBitWidth(), 1);
-m_integer |= APSInt(std::move(mask), m_integer.isUnsigned());
- }
- return true;
-}
-break;
+ llvm::APInt sign_bit = llvm::APInt::getSignMask(sign_bit_pos + 1);
+ llvm::APInt bitwize_and = m_integer & sign_bit;
+ if (bitwize_and.getBoolValue()) {
+llvm::APInt mask = ~(sign_bit) + llvm::APInt(m_integer.getBitWidth(), 1);
+m_integer |= APSInt(std::move(mask), m_integer.isUnsigned());
}
- return false;
+ return true;
}
size_t Scalar::GetAsMemoryData(void *dst, size_t dst_len,
>From 5fbf491d0781c1dcce6bdc727844e75c527f6473 Mon Sep 17 00:00:00 2001
From: Shivam Gupta
Date: Wed, 24 Jul 2024 14:36:15 +0200
Subject: [PATCH 3/4] adjust assert to fix
SymbolFile/DWARF/debug-types-expressions.test
---
lldb/source/Utility/Scalar.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 496f402a74114..42247f658da13 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -745,8 +745,8 @@ Status Scalar::SetValueFromData(const DataExtractor &data,
bool Scalar::SignExtend(uint32_t sign_bit_pos) {
const uint32_t max_bit_pos = GetByteSize() * 8;
- assert(sign_bit_pos < max_bit_pos);
+ assert(sign_bit_pos <= max_bit_pos);
if (m_type != Scalar::e_int || sign_bit_pos >= (max_bit_pos - 1)) {
return false;
}
>From 2a7cbea5c38b57ed412c1415254b2308b2bd1e16 Mon Sep 17 00:00:00 2001
From: xgupta
Date: Fri, 26 Jul 2024 11:03:32 +0200
Subject: [PATCH 4/4] address review comment
---
lldb/source/Utility/Scalar.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 42247f658da13..facb3e5a6a1a9 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source
[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)
labath wrote: > If that's not what's happening right now, then we ought to fix it. Or at least, understand why is that impossible. 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)
@@ -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
labath wrote:
LLDB allocates memory inside the target process, either by calling mmap (that's
what the `PrepareTrivialCall` function you're updating in this patch does), or
through a server-specific mechanism the `_M` packet.
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] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)
https://github.com/labath 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] Optimized lldb-server memory usage (PR #100666)
@@ -1145,8 +1145,8 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanWrite())
socket_pipe.CloseWriteFileDescriptor();
if (socket_pipe.CanRead()) {
-char port_cstr[PATH_MAX] = {0};
-port_cstr[0] = '\0';
+// The port number may be "1024\0".."65535\0".
labath wrote:
Technically, if you're running as root, it could also be one of the smaller
values. I'd just document the largest value.
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] Optimized lldb-server memory usage (PR #100666)
https://github.com/labath approved this pull request. 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][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/100710
>From 9136653363bb7fc58e0b7f55a714d36d4613fe24 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 26 Jul 2024 01:19:02 +0100
Subject: [PATCH 1/3] [lldb][TypeSystemClang][NFC] Clean up
TypeSystemClang::GetBitSize
This patch does following NFC changes to TypeSystemClang::GetBitSize:
* Factor out the Objective-C logic into a helper function.
* We had a redundant check for `GetCompleteType` in the `RecordType`
case. We can remove that switch case entirely and rely on the
`default` case.
* Introduce a new case for `FunctionProto`. I don't see a good reason
for special-casing this in the `default` case.
* Introduce a new case for `IncompleteArray`.
The motivation for this is that there are a few issues around VLAs
(i.e., `Type::IncompleteArray`) whose fixes will be easier to reason
about after this refactor.
---
.../TypeSystem/Clang/TypeSystemClang.cpp | 114 +-
.../TypeSystem/Clang/TypeSystemClang.h| 3 +
2 files changed, 61 insertions(+), 56 deletions(-)
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index f70efe5ed57e4..3f7a6344542f4 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4725,67 +4725,69 @@ TypeSystemClang::GetFloatTypeSemantics(size_t
byte_size) {
return llvm::APFloatBase::Bogus();
}
+std::optional
+TypeSystemClang::GetObjCBitSize(QualType qual_type,
+ExecutionContextScope *exe_scope) {
+ assert(qual_type->isObjCObjectOrInterfaceType());
+ ExecutionContext exe_ctx(exe_scope);
+ Process *process = exe_ctx.GetProcessPtr();
+ if (process) {
+if (ObjCLanguageRuntime *objc_runtime =
+ObjCLanguageRuntime::Get(*process)) {
+ if (std::optional bit_size =
+ objc_runtime->GetTypeBitSize(GetType(qual_type)))
+return *bit_size;
+}
+ } else {
+static bool g_printed = false;
+if (!g_printed) {
+ StreamString s;
+ DumpTypeDescription(qual_type.getAsOpaquePtr(), s);
+
+ llvm::outs() << "warning: trying to determine the size of type ";
+ llvm::outs() << s.GetString() << "\n";
+ llvm::outs() << "without a valid ExecutionContext. this is not "
+ "reliable. please file a bug against LLDB.\n";
+ llvm::outs() << "backtrace:\n";
+ llvm::sys::PrintStackTrace(llvm::outs());
+ llvm::outs() << "\n";
+ g_printed = true;
+}
+ }
+
+ return getASTContext().getTypeSize(qual_type) +
+ getASTContext().getTypeSize(getASTContext().ObjCBuiltinClassTy);
+}
+
std::optional
TypeSystemClang::GetBitSize(lldb::opaque_compiler_type_t type,
ExecutionContextScope *exe_scope) {
- if (GetCompleteType(type)) {
-clang::QualType qual_type(GetCanonicalQualType(type));
-const clang::Type::TypeClass type_class = qual_type->getTypeClass();
-switch (type_class) {
-case clang::Type::Record:
- if (GetCompleteType(type))
-return getASTContext().getTypeSize(qual_type);
- else
-return std::nullopt;
- break;
+ if (!GetCompleteType(type))
+return std::nullopt;
-case clang::Type::ObjCInterface:
-case clang::Type::ObjCObject: {
- ExecutionContext exe_ctx(exe_scope);
- Process *process = exe_ctx.GetProcessPtr();
- if (process) {
-if (ObjCLanguageRuntime *objc_runtime =
-ObjCLanguageRuntime::Get(*process)) {
- if (std::optional bit_size =
- objc_runtime->GetTypeBitSize(GetType(qual_type)))
-return *bit_size;
-}
- } else {
-static bool g_printed = false;
-if (!g_printed) {
- StreamString s;
- DumpTypeDescription(type, s);
-
- llvm::outs() << "warning: trying to determine the size of type ";
- llvm::outs() << s.GetString() << "\n";
- llvm::outs() << "without a valid ExecutionContext. this is not "
- "reliable. please file a bug against LLDB.\n";
- llvm::outs() << "backtrace:\n";
- llvm::sys::PrintStackTrace(llvm::outs());
- llvm::outs() << "\n";
- g_printed = true;
-}
- }
-}
- [[fallthrough]];
-default:
- const uint32_t bit_size = getASTContext().getTypeSize(qual_type);
- if (bit_size == 0) {
-if (qual_type->isIncompleteArrayType())
- return getASTContext().getTypeSize(
- qual_type->getArrayElementTypeNoTypeQual()
- ->getCanonicalTypeUnqualified());
- }
- if (qual_type->isObjCObjectOrInterfaceType())
-return bit_size +
- getASTContext().getTypeSize(getASTContext().ObjCBuiltinClassTy);
- // Function types actually have a size of 0, that's not an error.
- if (qual_typ
[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)
@@ -0,0 +1,80 @@
+// RUN: %clangxx_host -gdwarf -std=c++11 -o %t %s
+// RUN: %lldb %t \
+// RUN: -o run \
+// RUN: -o "frame var --show-types f" \
+// RUN: -o "frame var vla0" \
+// RUN: -o "frame var fla0" \
+// RUN: -o "frame var fla1" \
+// RUN: -o "frame var vla01" \
+// RUN: -o "frame var vla10" \
+// RUN: -o "frame var vlaN" \
+// RUN: -o "frame var vlaNM" \
+// RUN: -o exit | FileCheck %s
+
+struct Foo {
+ static constexpr int n = 1;
+ int m_vlaN[n];
+
+ int m_vla0[0];
+};
+
+int main() {
+ Foo f;
+ f.m_vlaN[0] = 60;
+
+ // CHECK: (lldb) frame var --show-types f
+ // CHECK-NEXT: (Foo) f = {
+ // CHECK-NEXT: (int[1]) m_vlaN = {
+ // CHECK-NEXT: (int) [0] = 60
+ // CHECK-NEXT: }
+ // CHECK-NEXT: (int[0]) m_vla0 = {}
+ // CHECK-NEXT: }
+
+ int vla0[0] = {};
+
+ // CHECK: (lldb) frame var vla0
+ // CHECK-NEXT: (int[0]) vla0 = {}
+
+ int fla0[] = {};
+
+ // CHECK: (lldb) frame var fla0
+ // CHECK-NEXT: (int[0]) fla0 = {}
+
+ int fla1[] = {42};
+
+ // CHECK: (lldb) frame var fla1
+ // CHECK-NEXT: (int[1]) fla1 = ([0] = 42)
+
+ int vla01[0][1];
+
+ // CHECK: (lldb) frame var vla01
+ // CHECK-NEXT: (int[0][1]) vla01 = {}
+
+ int vla10[1][0];
+
+ // CHECK: (lldb) frame var vla10
+ // CHECK-NEXT: (int[1][0]) vla10 = ([0] = int[0]
+
+ int n = 3;
+ int vlaN[n];
+ for (int i = 0; i < n; ++i)
+vlaN[i] = -i;
+
+ // CHECK: (lldb) frame var vlaN
+ // CHECK-NEXT: (int[]) vlaN = ([0] = 0, [1] = -1, [2] = -2)
+
+ int m = 2;
+ int vlaNM[n][m];
+ for (int i = 0; i < n; ++i)
+for (int j = 0; j < m; ++j)
+ vlaNM[i][j] = i + j;
+
+ // FIXME: multi-dimensional VLAs aren't well supported
+ // CHECK: (lldb) frame var vlaNM
+ // CHECK-NEXT: (int[][]) vlaNM = {
+ // CHECK-NEXT: [0] = ([0] = 0, [1] = 1, [2] = 1)
+ // CHECK-NEXT: [1] = ([0] = 1, [1] = 1, [2] = 2)
+ // CHECK-NEXT: }
Michael137 wrote:
This is also broken without this patch. E.g., accessing elements of a VLA with
non-constant bounds will return garbage. My hunch is that we just calculate the
stride incorrectly (or something related to calculating children count).
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/100670 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)
https://github.com/labath requested changes to this pull request. I wanted to change this code to use threads for a long time, but the idea of using a per-thread virtual file system absolutely terrifies me. That only works is all of the accesses go through the file system (no direct syscalls) and if we're very strict about which code executes on which thread. Right now, I don't think we're either, and I don't see how we could ever achieve it. (That's not exactly true for the code in the lldb-server, but we also don't really have enforcable rules for which code can be run in the lldb-server, and the code this is changing affects all of lldb). (Also, I guess this is the reason for the ETXTBSY workaround) One obvious and safe (though less performant and less satisfying) alternative is to replace the fork with spawning a new process (fork+execve) instead. Have you considered that? https://github.com/llvm/llvm-project/pull/100670 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)
@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
bytes_read += result;
if (bytes_read == size || result == 0)
break;
+
+// This is the workaround for the following bug in Linux multithreading
+// select() https://bugzilla.kernel.org/show_bug.cgi?id=546
+// ReadWithTimeout() with a non-zero timeout is used only to
+// read the port number from the gdbserver pipe
+// in GDBRemoteCommunication::StartDebugserverProcess().
+// The port number may be "1024\0".."65535\0".
+if (timeout.count() > 0 && size == 6 && bytes_read == 5 &&
+static_cast(buf)[4] == '\0') {
+ break;
+}
labath wrote:
It sounds like the consensus on that bug is that this is the application's
(i.e. our) fault. We should fix the issue instead.
https://github.com/llvm/llvm-project/pull/100670
___
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] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
https://github.com/labath commented: This looks much better, and it looks like @dzhidzhoev is just about to remove some of the same XFAILS as well (in #100628). I suggest you two collaborate on the remaining ones. 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] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)
labath wrote: One way I can imagine this happening is if the FileSystem instance was local to a `GDBRemoteCommunicationServerPlatform` instance -- rather than the thread it happens to be (mostly) running on. This will require more changes to, basically, plumb the filesystem instance to every place that needs to be used from the platform object, but I think that's actually a good thing. It will give us a record of which code is prepared to deal with virtualized filesystems and which one isn't. I just don't think we can assume that all our code (present and future) will handle the per-thread filesystem situation correctly. (That said, it still may be better to just spawn a new process instead. I don't think this is a particularly hot code path (I think the test suite is basically the only user of multithreaded platforms), and it will make sure we don't hit the ETXTBSY issue). https://github.com/llvm/llvm-project/pull/100670 ___ 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)
rocallahan wrote: One thing that's not entirely clear to me from the discussion so far: apparently the public API rules allow adding an overload of `SBProcess::Continue()` with a direction parameter. Do they allow just adding a direction parameter to the existing overload *with a default value*? Because the latter seems exactly like the former in practice, to me. 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] Refactor TypeQuery::ContextMatches (PR #99305)
@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) {
bool TypeQuery::ContextMatches(
llvm::ArrayRef context_chain) const {
- if (GetExactMatch() || context_chain.size() == m_context.size())
-return ::contextMatches(context_chain, m_context);
-
- // We don't have an exact match, we need to bottom m_context.size() items to
- // match for a successful lookup.
- if (context_chain.size() < m_context.size())
-return false; // Not enough items in context_chain to allow for a match.
-
- size_t compare_count = context_chain.size() - m_context.size();
- return ::contextMatches(
- llvm::ArrayRef(context_chain.data() + compare_count,
- m_context.size()),
- m_context);
+ auto ctx = context_chain.rbegin(), ctx_end = context_chain.rend();
+ for (auto pat = m_context.rbegin(), pat_end = m_context.rend();
+ pat != pat_end;) {
+
+// Handle AnyModule matches. These are tricky as they can match any number
labath wrote:
Hmmm... Ping? Do we still need to wait for opinions from @adrian-prantl
@augusto2112 @kastiglione or should I just go ahead and implement the
simplified version?
https://github.com/llvm/llvm-project/pull/99305
___
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)
labath wrote: > One thing that's not entirely clear to me from the discussion so far: > apparently the public API rules allow adding an overload of > `SBProcess::Continue()` with a direction parameter. Do they allow just adding > a direction parameter to the existing overload _with a default value_? > Because the latter seems exactly like the former in practice, to me. The two are different when it comes to the ABI. Adding a new function just adds a new symbol. Adding a default argument to an existing function adds a new symbol (the same one as in the first case, as default arguments aren't part of the ABI -- that can be both good and bad, but I digress..) *and* removes an existing one. That means the code built against the old lldb wouldn't be able to run against the new one (without recompiling). That's what we want to preserve. 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] Refactor TypeQuery::ContextMatches (PR #99305)
@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) {
bool TypeQuery::ContextMatches(
llvm::ArrayRef context_chain) const {
- if (GetExactMatch() || context_chain.size() == m_context.size())
-return ::contextMatches(context_chain, m_context);
-
- // We don't have an exact match, we need to bottom m_context.size() items to
- // match for a successful lookup.
- if (context_chain.size() < m_context.size())
-return false; // Not enough items in context_chain to allow for a match.
-
- size_t compare_count = context_chain.size() - m_context.size();
- return ::contextMatches(
- llvm::ArrayRef(context_chain.data() + compare_count,
- m_context.size()),
- m_context);
+ auto ctx = context_chain.rbegin(), ctx_end = context_chain.rend();
+ for (auto pat = m_context.rbegin(), pat_end = m_context.rend();
+ pat != pat_end;) {
+
+// Handle AnyModule matches. These are tricky as they can match any number
Michael137 wrote:
@adrian-prantl was OOO for a couple of weeks, but should be back today. Not
sure he'll see this today (I suspect the review queue might be quite high). I
can help run the swift plugin tests if you end up refactoring this. Think it
would also be fine to merge this and rework it afterwards. Whatever you prefer
https://github.com/llvm/llvm-project/pull/99305
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches (PR #99305)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/99305 ___ 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)
https://github.com/rocallahan updated
https://github.com/llvm/llvm-project/pull/99736
>From e9a44b4cfd2e3423fbf5ac75124530cc2bb8afed Mon Sep 17 00:00:00 2001
From: Robert O'Callahan
Date: Fri, 19 Jul 2024 22:46:42 +1200
Subject: [PATCH] [lldb] Implement basic support for reverse-continue
This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command
for this will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`)
providing support for the `bc` and `bs` packets. `lldb-server`
does not support those packets, and there is no plan to change that.
So, for testing purposes, `lldbreverse.py` wraps `lldb-server`
with a Python implementation of *very limited* record-and-replay
functionality.
---
lldb/include/lldb/API/SBProcess.h | 1 +
lldb/include/lldb/Target/Process.h| 20 +-
lldb/include/lldb/Target/StopInfo.h | 3 +
lldb/include/lldb/lldb-enumerations.h | 6 +
.../Python/lldbsuite/test/gdbclientutils.py | 5 +-
.../Python/lldbsuite/test/lldbgdbproxy.py | 175
.../Python/lldbsuite/test/lldbreverse.py | 418 ++
.../Python/lldbsuite/test/lldbtest.py | 2 +
lldb/source/API/SBProcess.cpp | 8 +-
lldb/source/API/SBThread.cpp | 2 +
.../source/Interpreter/CommandInterpreter.cpp | 3 +-
.../Process/Linux/NativeThreadLinux.cpp | 3 +
.../Process/MacOSX-Kernel/ProcessKDP.cpp | 9 +-
.../Process/MacOSX-Kernel/ProcessKDP.h| 2 +-
.../Process/Windows/Common/ProcessWindows.cpp | 8 +-
.../Process/Windows/Common/ProcessWindows.h | 2 +-
.../GDBRemoteCommunicationClient.cpp | 22 +
.../gdb-remote/GDBRemoteCommunicationClient.h | 6 +
.../GDBRemoteCommunicationServerLLGS.cpp | 1 +
.../Process/gdb-remote/ProcessGDBRemote.cpp | 78 +++-
.../Process/gdb-remote/ProcessGDBRemote.h | 2 +-
.../Process/scripted/ScriptedProcess.cpp | 11 +-
.../Process/scripted/ScriptedProcess.h| 2 +-
lldb/source/Target/Process.cpp| 25 +-
lldb/source/Target/StopInfo.cpp | 29 ++
lldb/source/Target/Thread.cpp | 8 +-
.../reverse-execution/Makefile| 3 +
.../TestReverseContinueBreakpoints.py | 115 +
.../TestReverseContinueNotSupported.py| 30 ++
.../functionalities/reverse-execution/main.c | 14 +
lldb/tools/lldb-dap/JSONUtils.cpp | 3 +
lldb/tools/lldb-dap/LLDBUtils.cpp | 1 +
32 files changed, 975 insertions(+), 42 deletions(-)
create mode 100644 lldb/packages/Python/lldbsuite/test/lldbgdbproxy.py
create mode 100644 lldb/packages/Python/lldbsuite/test/lldbreverse.py
create mode 100644 lldb/test/API/functionalities/reverse-execution/Makefile
create mode 100644
lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py
create mode 100644
lldb/test/API/functionalities/reverse-execution/TestReverseContinueNotSupported.py
create mode 100644 lldb/test/API/functionalities/reverse-execution/main.c
diff --git a/lldb/include/lldb/API/SBProcess.h
b/lldb/include/lldb/API/SBProcess.h
index 778be79583990..ba069014defd2 100644
--- a/lldb/include/lldb/API/SBProcess.h
+++ b/lldb/include/lldb/API/SBProcess.h
@@ -159,6 +159,7 @@ class LLDB_API SBProcess {
lldb::SBError Destroy();
lldb::SBError Continue();
+ lldb::SBError Continue(RunDirection direction);
lldb::SBError Stop();
diff --git a/lldb/include/lldb/Target/Process.h
b/lldb/include/lldb/Target/Process.h
index c8475db8ae160..51d9c166fdda5 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -874,10 +874,10 @@ class Process : public
std::enable_shared_from_this,
/// \see Thread:Resume()
/// \see Thread:Step()
/// \see Thread:Suspend()
- Status Resume();
+ Status Resume(lldb::RunDirection direction = lldb::eRunForward);
/// Resume a process, and wait for it to stop.
- Status ResumeSynchronous(Stream *stream);
+ Status ResumeSynchronous(Stream *stream, lldb::RunDirection direction =
lldb::eRunForward);
/// Halts a running process.
///
@@ -1129,10 +1129,15 @@ class Process : public
std::enable_shared_from_this,
/// \see Thread:Resume()
/// \see Thread:Step()
/// \see Thread:Suspend()
- virtual Status DoResume() {
+ virtual Status DoResume(lldb::RunDirection direction) {
Status error;
-error.SetErrorStringWithFormatv(
-"error: {0} does not support resuming processes", GetPluginName());
+if (direction == lldb::RunDirection::eRunForward) {
+ error.SetErrorStringWithFormatv(
+ "error: {0} does not support resuming processes", GetPluginName());
+} else {
+ error.SetErrorStringWithFormatv(
+ "error: {0} does not support reverse execution of processes",
GetPluginName());
+}
return error;
}
@@ -2367,6 +2372,8 @@ class Process
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)
rocallahan wrote: > The two are different when it comes to the ABI Yeah OK. I've fixed that. 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][win][x86_64] XFAIL already failing Shell tests (PR #100476)
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
```
PASS: lldb-shell :: Settings/TestEchoCommands.test (315 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at line 1
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet -x -b -o
'settings set interpreter.echo-comment-commands true' -s
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in |
c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsAll.out
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet' -x -b -o
'settings set interpreter.echo-comment-commands true' -s
'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in'
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsAll.out'
# note: command had no output on stdout or stderr
# RUN: at line 2
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet -x -b -o
'settings set interpreter.echo-comment-commands false' -s
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in |
c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsNoComments.out
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet' -x -b -o
'settings set interpreter.echo-comment-commands false' -s
'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in'
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsNoComments.out'
# note: command had no output on stdout or stderr
# RUN: at line 3
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet -x -b -o
'settings set interpreter.echo-commands false' -s
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in |
c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsNone.out
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet' -x -b -o
'settings set interpreter.echo-commands false' -s
'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in'
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsNone.out'
# note: command had no output on stdout or stderr
# RUN: at line 7
echo start
>C:\build-lldb-native\tools\lldb\test\Shell\Settings\Output\TestEchoCommands.test.tmp.file
# executed command: echo start
# note: command had no output on stdout or stderr
# RUN: at line 8
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet -x -b
--source-quietly -s C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in
>>C:\build-lldb-native\tools\lldb\test\Shell\Settings\Output\TestEchoCommands.test.tmp.file
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet' -x -b
--source-quietly -s 'C:\lldb\test\Shell\Settings/Inputs/EchoCommandsTest.in'
# note: command had no output on stdout or stderr
# RUN: at line 9
echo done
>>C:\build-lldb-native\tools\lldb\test\Shell\Settings\Output\TestEchoCommands.test.tmp.file
# executed command: echo done
# note: command had no output on stdout or stderr
# RUN: at line 10
c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\Settings/Inputs/EchoCommandsQuiet.out
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,5 +1,7 @@
// clang-format off
+// XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
As far as I understand, NativePDB tests only run for Windows host+Windows
target, contrary to the tests from the PDB folder which we managed to run on
Linux target as part of our effort here
https://discourse.llvm.org/t/rfc-lldb-support-remote-run-of-shell-tests/80072/10.
It's surprising that they didn't pass with your config
```
PASS: lldb-shell :: SymbolFile/NativePDB/stack_unwinding01.cpp (533 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at line 4
'C:\Python312\python.exe' C:\lldb\test\Shell\helper\build.py --compiler=any
--arch=64 --tools-dir=C:/build-lldb-native/./bin
--libs-dir=C:/build-lldb-native/./lib --compiler=clang-cl --nodefaultlib -o
C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\NativePDB\Output\stack_unwinding01.cpp.tmp.exe
-- C:\lldb\test\Shell\SymbolFile\NativePDB\stack_unwinding01.cpp
# executed command: 'C:\Python312\python.exe'
'C:\lldb\test\Shell\helper\build.py' --compiler=any --arch=64
--tools-dir=C:/build-lldb-native/./bin --libs-dir=C:/build-lldb-native/./lib
--compiler=clang-cl --nodefaultlib -o
'C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\NativePDB\Output\stack_unwinding01.cpp.tmp.exe'
-- 'C:\lldb\test\Shell\SymbolFile\NativePDB\stack_unwinding01.cpp'
# .---command stdout
# | Cleaning stack_unwinding01.ilk
# | Cleaning stack_unwinding01.cpp.tmp.exe-stack_unwinding01.obj
# | Cleaning stack_unwinding01.cpp.tmp.pdb
# | Cleaning stack_unwinding01.cpp.tmp.exe
# |
# |
# |
# | compiling stack_unwinding01.cpp ->
stack_unwinding01.cpp.tmp.exe-stack_unwinding01.obj
# | STDOUT:
# |
# |
# |
# |
# | linking stack_unwinding01.cpp.tmp.exe-stack_unwinding01.obj ->
stack_unwinding01.cpp.tmp.exe
# | STDOUT:
# |
# `-
# RUN: at line 5
env LLDB_USE_NATIVE_PDB_READER=1 c:\build-lldb-native\bin\lldb.exe
--no-lldbinit -S C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet
-f
C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\NativePDB\Output\stack_unwinding01.cpp.tmp.exe
-s
C:\lldb\test\Shell\SymbolFile\NativePDB/Inputs/stack_unwinding01.lldbinit 2>&1
| c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\SymbolFile\NativePDB\stack_unwinding01.cpp
# executed command: env LLDB_USE_NATIVE_PDB_READER=1
'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet' -f
'C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\NativePDB\Output\stack_unwinding01.cpp.tmp.exe'
-s 'C:\lldb\test\Shell\SymbolFile\NativePDB/Inputs/stack_unwinding01.lldbinit'
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\SymbolFile\NativePDB\stack_unwinding01.cpp'
# note: command had no output on stdout or stderr
```
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{{.*}}
dzhidzhoev wrote:
Interestingly, this test is green on our Windows native CI. It uses cmd.exe.
Here's the log:
```
PASS: lldb-shell :: Driver/TestConvenienceVariables.test (88 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at line 2
mkdir -p
C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp
# executed command: mkdir -p
'C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp'
# note: command had no output on stdout or stderr
# RUN: at line 3
'C:\Python312\python.exe' C:\lldb\test\Shell\helper\build.py --compiler=any
--arch=64 --tools-dir=C:/build-lldb-native/./bin
--libs-dir=C:/build-lldb-native/./lib
C:\lldb\test\Shell\Driver/Inputs/hello.cpp -o
C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp/target.out
# executed command: 'C:\Python312\python.exe'
'C:\lldb\test\Shell\helper\build.py' --compiler=any --arch=64
--tools-dir=C:/build-lldb-native/./bin --libs-dir=C:/build-lldb-native/./lib
'C:\lldb\test\Shell\Driver/Inputs/hello.cpp' -o
'C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp/target.out'
# .---command stdout
# | Cleaning hello.ilk
# | Cleaning target.out-hello.obj
# | Cleaning target.pdb
# | Cleaning target.out
# |
# |
# |
# | compiling hello.cpp -> target.out-hello.obj
# | STDOUT:
# |
# |
# |
# |
# | linking target.out-hello.obj -> target.out
# | STDOUT:
# |
# `-
# RUN: at line 4
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet
C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp/target.out
-s C:\lldb\test\Shell\Driver/Inputs/convenience.in -o quit |
c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\Driver\TestConvenienceVariables.test
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet'
'C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp/target.out'
-s 'C:\lldb\test\Shell\Driver/Inputs/convenience.in' -o quit
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\Driver\TestConvenienceVariables.test'
# note: command had no output on stdout or stderr
--
```
However, I'm unsure if the quotes are printed in log the same way they are
passed to cmd.
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"
dzhidzhoev wrote:
The same as for TestConvenienceVariables.test:
```
PASS: lldb-shell :: Driver/TestSingleQuote.test (75 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at line 2
c:\build-lldb-native\bin\clang.exe
--target=specify-a-target-or-use-a-_host-substitution
--target=x86_64-pc-windows-msvc
-fmodules-cache-path=C:/build-lldb-native/lldb-test-build.noindex/module-cache-clang\lldb-shell
C:\lldb\test\Shell\Driver/Inputs/hello.c -g -o
"C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestSingleQuote.test.tmp-'pat"
# executed command: 'c:\build-lldb-native\bin\clang.exe'
--target=specify-a-target-or-use-a-_host-substitution
--target=x86_64-pc-windows-msvc
'-fmodules-cache-path=C:/build-lldb-native/lldb-test-build.noindex/module-cache-clang\lldb-shell'
'C:\lldb\test\Shell\Driver/Inputs/hello.c' -g -o
'C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestSingleQuote.test.tmp-'"'"'pat'
# .---command stderr
# | clang: warning: argument unused during compilation:
'-fmodules-cache-path=C:/build-lldb-native/lldb-test-build.noindex/module-cache-clang\lldb-shell'
[-Wunused-command-line-argument]
# `-
# RUN: at line 3
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet -s
C:\lldb\test\Shell\Driver\TestSingleQuote.test
"C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestSingleQuote.test.tmp-'pat"
| c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\Driver\TestSingleQuote.test
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet' -s
'C:\lldb\test\Shell\Driver\TestSingleQuote.test'
'C:\build-lldb-native\tools\lldb\test\Shell\Driver\Output\TestSingleQuote.test.tmp-'"'"'pat'
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\Driver\TestSingleQuote.test'
# note: command had no output on stdout or stderr
--
```
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,5 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
We have it green as well
```
PASS: lldb-shell :: SymbolFile/DWARF/x86/dead-code-filtering.yaml (389 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at line 1
c:\build-lldb-native\bin\yaml2obj.exe
C:\lldb\test\Shell\SymbolFile\DWARF\x86\dead-code-filtering.yaml >
C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\DWARF\x86\Output\dead-code-filtering.yaml.tmp
# executed command: 'c:\build-lldb-native\bin\yaml2obj.exe'
'C:\lldb\test\Shell\SymbolFile\DWARF\x86\dead-code-filtering.yaml'
# note: command had no output on stdout or stderr
# RUN: at line 2
c:\build-lldb-native\bin\lldb-test.exe symbols
C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\DWARF\x86\Output\dead-code-filtering.yaml.tmp
| c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\SymbolFile\DWARF\x86\dead-code-filtering.yaml
--check-prefix=TEST
# executed command: 'c:\build-lldb-native\bin\lldb-test.exe' symbols
'C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\DWARF\x86\Output\dead-code-filtering.yaml.tmp'
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\SymbolFile\DWARF\x86\dead-code-filtering.yaml'
--check-prefix=TEST
# note: command had no output on stdout or stderr
# RUN: at line 3
c:\build-lldb-native\bin\lldb.exe --no-lldbinit -S
C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet
C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\DWARF\x86\Output\dead-code-filtering.yaml.tmp
-o "image dump line-table a.c" -o "image lookup -n _start" -o "image lookup -n
f" -o exit | c:\build-lldb-native\bin\filecheck.exe
C:\lldb\test\Shell\SymbolFile\DWARF\x86\dead-code-filtering.yaml
# executed command: 'c:\build-lldb-native\bin\lldb.exe' --no-lldbinit -S
'C:/build-lldb-native/tools/lldb\test\Shell\lit-lldb-init-quiet'
'C:\build-lldb-native\tools\lldb\test\Shell\SymbolFile\DWARF\x86\Output\dead-code-filtering.yaml.tmp'
-o 'image dump line-table a.c' -o 'image lookup -n _start' -o 'image lookup -n
f' -o exit
# note: command had no output on stdout or stderr
# executed command: 'c:\build-lldb-native\bin\filecheck.exe'
'C:\lldb\test\Shell\SymbolFile\DWARF\x86\dead-code-filtering.yaml'
# note: command had no output on stdout or stderr
--
```
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] Remove decorator from XPASSes x86/Windows (PR #100628)
https://github.com/dzhidzhoev closed 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] 6a1a393 - [LLDB] Remove decorator from XPASSes x86/Windows (#100628)
Author: Vladislav Dzhidzhoev Date: 2024-07-26T14:28:11+02:00 New Revision: 6a1a393997fb5f7bdb01943ed48dc72d48861824 URL: https://github.com/llvm/llvm-project/commit/6a1a393997fb5f7bdb01943ed48dc72d48861824 DIFF: https://github.com/llvm/llvm-project/commit/6a1a393997fb5f7bdb01943ed48dc72d48861824.diff LOG: [LLDB] Remove decorator from XPASSes x86/Windows (#100628) This patch removes XFAIL decorators from tests that are passing on x86 Windows. Corresponding XFAILs for AArch64 were removed here 7daa9a9b40a22. Added: Modified: lldb/test/API/lang/cpp/class-template-non-type-parameter-pack/TestClassTemplateNonTypeParameterPack.py lldb/test/API/lang/cpp/class-template-type-parameter-pack/TestClassTemplateTypeParameterPack.py Removed: 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][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
@@ -12,6 +12,7 @@ class MultipleSlidesTestCase(TestBase): NO_DEBUG_INFO_TESTCASE = True +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) dzhidzhoev wrote: Could you provide a failure log for this? It passes on our CI (Windows native x86_64). ``` PASS: lldb-api :: functionalities/multiple-slides/TestMultipleSlides.py (530 of 1191) Script: -- C:/Python312/python.exe C:/lldb\test\API\dotest.py -u CXXFLAGS -u CFLAGS --env OBJCOPY=C:/build-lldb-native/./bin/llvm-objcopy.exe --env STRIP=C:/build-lldb-native/./bin/llvm-strip.exe --env LLVM_LIBS_DIR=C:/build-lldb-native/./lib --env LLVM_INCLUDE_DIR=C:/build-lldb-native/include --env LLVM_TOOLS_DIR=C:/build-lldb-native/./bin --arch x86_64 --build-dir C:/build-lldb-native/lldb-test-build.noindex --lldb-module-cache-dir C:/build-lldb-native/lldb-test-build.noindex/module-cache-lldb\lldb-api --clang-module-cache-dir C:/build-lldb-native/lldb-test-build.noindex/module-cache-clang\lldb-api --executable C:/build-lldb-native/./bin/lldb.exe --make c:/gl/b1/3rdpaty/bin/make-wfix.exe --compiler C:/build-lldb-native/./bin/clang.exe --dsymutil C:/build-lldb-native/./bin/dsymutil.exe --llvm-tools-dir C:/build-lldb-native/./bin --lldb-obj-root C:/build-lldb-native/tools/lldb --lldb-libs-dir C:/build-lldb-native/./lib --skip-category=watchpoint C:\lldb\test\API\functionalities\multiple-slides -p TestMultipleSlides.py -- Exit Code: 0 Command Output (stdout): -- lldb version 20.0.0git (https://gitlab-ci-token:glcbt-64_rzntyt5_udr5slklb...@gitlab.ninolab.accesssoftek.com/accesssoftek/lldb-test-scripts.git revision cbd39658b6aed4dbb66a2b775096974c9087e93d) clang revision cbd39658b6aed4dbb66a2b775096974c9087e93d llvm revision cbd39658b6aed4dbb66a2b775096974c9087e93d Skipping the following test categories: ['watchpoint', 'libc++', 'libstdcxx', 'dwo', 'dsym', 'gmodules', 'debugserver', 'objc', 'fork', 'pexpect'] -- Command Output (stderr): -- PASS: LLDB (C:\build-lldb-native\bin\clang.exe-x86_64) :: test_mulitple_slides (TestMultipleSlides.MultipleSlidesTestCase.test_mulitple_slides) -- Ran 1 test in 2.447s OK -- ``` 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] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
@@ -12,6 +12,7 @@ class MultipleSlidesTestCase(TestBase): NO_DEBUG_INFO_TESTCASE = True +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) dzhidzhoev wrote: Also, it may be worth cherry-picking this https://github.com/llvm/llvm-project/commit/58d22f1b665ca8810c4de341426247b7b5a69548 to have build commands and outputs in the log without tracing hassle. 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] Add ABI library to Makefile.rules link flags (PR #99589)
dzhidzhoev wrote: > Libc++ supports a [large > number](https://github.com/llvm/llvm-project/blob/6235698f47828747d3b1b0418e547e2e4ff9138f/libcxx/cmake/Modules/HandleLibCXXABI.cmake#L85) > of configurations when in comes to the ABI library. > > I think the most common are: shared-libcxx+shared-libcxxabi (where this > change should be a no-op) and static-libcxx+static-libcxxabi (where this flag > is required to build). > > However, I also found evidence of configurations which embed the abi library > into libcxx (which would break with this flag, as `-lc++abi` will find > nothing, or the wrong library), or link the c++ library to the gnu abi > library (libsupc++, where this flag would cause duplicate definitions or > general weirdness). > > If noone is using these configurations, then I think this patch is fine. If > not, we will have to do something more elaborate. I suspect it's safe, but > lets wait a while before committing to give people a chance to notice this. Do you think it should be pushed now? https://github.com/llvm/llvm-project/pull/99589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Add ABI library to Makefile.rules link flags (PR #99589)
https://github.com/labath approved this pull request. I suggest Monday. If anything breaks, at least there'll be someone around to do something about it. https://github.com/llvm/llvm-project/pull/99589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)
slydiman wrote: > to replace the fork with spawning a new process (fork+execve) instead. Have > you considered that? To fix all gdb port mapping issues we need a common port mapping available to all platform connections. It is possible only with the multithreading. https://github.com/llvm/llvm-project/pull/100670 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)
@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
bytes_read += result;
if (bytes_read == size || result == 0)
break;
+
+// This is the workaround for the following bug in Linux multithreading
+// select() https://bugzilla.kernel.org/show_bug.cgi?id=546
+// ReadWithTimeout() with a non-zero timeout is used only to
+// read the port number from the gdbserver pipe
+// in GDBRemoteCommunication::StartDebugserverProcess().
+// The port number may be "1024\0".."65535\0".
+if (timeout.count() > 0 && size == 6 && bytes_read == 5 &&
+static_cast(buf)[4] == '\0') {
+ break;
+}
slydiman wrote:
I don't think so. Note select() works fine with the pipe closed on other side
in the single thread. select() hangs in case of simultaneously calls from few
threads. I tried to connect to `lldb-server platform` and launch `lldb-server
gdbserver` in few threads. It works 50/50 in case of 2 threads and 100% failed
in case of 3+ threads. Instead of using select() I tried
- use poll()
- use read(size = 0)
- use non blocked pipe and call read() w/o select() or poll()
- change pipe buffer size
Nothing helped. It is the bug in the kernel. read() will hang too if the pipe
is closed on the other side. Non blocking read() will return EAGAIN instead of
0. The system just does not recognize the closed pipe in case of multithreading.
So, I don't see a way to fix this on Linux. The only way is a workaround.
https://github.com/llvm/llvm-project/pull/100670
___
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 updated
https://github.com/llvm/llvm-project/pull/100666
>From 0e451f16b91bab2bc2cd1375eb02e4fe71998790 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 02:40:49 +0400
Subject: [PATCH 1/3] [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.
>From 4562af94a7417575fec100e5bbe745b21870e6fc Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 11:55:08 +0400
Subject: [PATCH 2/3] Removed the redundant line.
---
.../source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index b961c0e42469a..07aa8209ca4ba 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1147,7 +1147,6 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanRead()) {
// 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.
error = socket_pipe.ReadWithTimeout(
>From ac300300b7e5c7a0cf1882d0a81efc24e587125c Mon Sep 17 00:00:00 2001
From: Dmitry Vassiliev
Date: Fri, 26 Jul 2024 18:53:20 +0400
Subject: [PATCH 3/3] Updated the 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 07aa8209ca4ba..5d0a3e31d0437 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1145,7 +1145,7 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanWrite())
socket_pipe.CloseWriteFileDescriptor();
if (socket_pipe.CanRead()) {
-// The port number may be "1024\0".."65535\0".
+// The port number may be up to "65535\0".
char port_cstr[6] = {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] f083764 - [lldb] Optimized lldb-server memory usage (#100666)
Author: Dmitry Vasilyev
Date: 2024-07-26T19:12:05+04:00
New Revision: f083764ba1ca35016c929683c8a5d918b5048100
URL:
https://github.com/llvm/llvm-project/commit/f083764ba1ca35016c929683c8a5d918b5048100
DIFF:
https://github.com/llvm/llvm-project/commit/f083764ba1ca35016c929683c8a5d918b5048100.diff
LOG: [lldb] Optimized lldb-server memory usage (#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.
Added:
Modified:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
Removed:
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 187370eb36cae..5d0a3e31d0437 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1145,8 +1145,8 @@ Status GDBRemoteCommunication::StartDebugserverProcess(
if (socket_pipe.CanWrite())
socket_pipe.CloseWriteFileDescriptor();
if (socket_pipe.CanRead()) {
-char port_cstr[PATH_MAX] = {0};
-port_cstr[0] = '\0';
+// The port number may be up to "65535\0".
+char port_cstr[6] = {0};
size_t num_bytes = sizeof(port_cstr);
// Read port from pipe with 10 second timeout.
error = socket_pipe.ReadWithTimeout(
___
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 closed 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] Add format eFormatEnumWithValues to ensure raw enum value is always shown (PR #90059)
DavidSpickett wrote: > When you display registers bitfields do you have a ValueObject? Yes: https://github.com/llvm/llvm-project/blob/6808e6c78edf63d2c0c9bd6fce168fe7e0a7d49f/lldb/source/Core/DumpRegisterValue.cpp#L47 I'm just calling `dump`, there's no register specific code there, ideally I wouldn't need any. > If so we can modify the ValueObject::GetSummary() to return the integer > value, but only if we have the format set to eFormatEnum. The output for > variables would be similar to what your tests expect, but we would just > modify the summary string that we return and then we don't need the new > format. I am not sure if a call to `dump` will end up using `GetSummary` or whether I'd need to loop over the children of the object myself, I'll look into it. > One reason I like this way of doing things is if you call > "valobj.GetValue()", and the format is set the enum with value, we will get > "foo (1)" as the value back from the value object. I would rather call > valobj.GetValue() and get "foo" and then call valojb.GetSummary() and get "1" When you put it like API style calls like that, I agree. `foo` is a "value" in the sense you could write it in your C source, `foo (1)` is not, it is literally a summary, an overview of the value, not usable in code. > If we have special display code for the register bitfields, they can call > these APIs when displaying register by default? By using the existing type infrastructure I avoided having to write printer code, so there isn't any right now. You could sort of do this by having options that only C++ code can set and are only used by the register dump code, this is what the original version of this PR did (which you can see [here](https://github.com/DavidSpickett/llvm-project/commit/cb875625d7159857345e3da2b9aa4f2436134bee) to compare). It's not great because it is this one off use case, but at least it's hidden from the command line and API users. Or I could add some kind of callback that only register dumping sets, that asks how to format the enum, but this is the same thing with different steps. Could wait and see if registers need anything else unique, and once enough of that exists, invest in custom code. After all, users can `register info` to see the values for an enum, and only a minority will need them anyway. ...and an off the wall idea I just thought of. These register types are only for display, and we could generate different ones for expressions (https://discourse.llvm.org/t/rfc-register-fields-in-expressions/79424) if needed. So instead of using `enum` for the field why not a `union` of `enum` and `unsigned`. The printed format might not be obvious to the reader but I'll give it a try, as it would sidestep the problems of the other solutions. https://github.com/llvm/llvm-project/pull/90059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][TypeSystemClang][NFC] Clean up TypeSystemClang::GetBitSize (PR #100674)
@@ -4725,67 +4725,69 @@ TypeSystemClang::GetFloatTypeSemantics(size_t
byte_size) {
return llvm::APFloatBase::Bogus();
}
+std::optional
+TypeSystemClang::GetObjCBitSize(QualType qual_type,
+ExecutionContextScope *exe_scope) {
+ assert(qual_type->isObjCObjectOrInterfaceType());
+ ExecutionContext exe_ctx(exe_scope);
+ Process *process = exe_ctx.GetProcessPtr();
+ if (process) {
+if (ObjCLanguageRuntime *objc_runtime =
+ObjCLanguageRuntime::Get(*process)) {
+ if (std::optional bit_size =
+ objc_runtime->GetTypeBitSize(GetType(qual_type)))
+return *bit_size;
+}
+ } else {
+static bool g_printed = false;
+if (!g_printed) {
+ StreamString s;
+ DumpTypeDescription(qual_type.getAsOpaquePtr(), s);
+
+ llvm::outs() << "warning: trying to determine the size of type ";
+ llvm::outs() << s.GetString() << "\n";
+ llvm::outs() << "without a valid ExecutionContext. this is not "
+ "reliable. please file a bug against LLDB.\n";
+ llvm::outs() << "backtrace:\n";
+ llvm::sys::PrintStackTrace(llvm::outs());
+ llvm::outs() << "\n";
JDevlieghere wrote:
That's fine as long as it gets either fixed or removed eventually.
https://github.com/llvm/llvm-project/pull/100674
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][TypeSystemClang][NFC] Clean up TypeSystemClang::GetBitSize (PR #100674)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/100674 ___ 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)
slydiman wrote: Of course lldb waits for the vFile:close response before sending the vRun packet and lldb-server actually closes the file handle (all of them). No any leaks. Otherwise this workaround wouldn't work. The behavior is the same on Linux and Windows targets. I launched 100 connections and 200 processes simultaneously on Windows (lldb-server gdbserver + a test app). I got 3..10 fails because of the error ERROR_SHARING_VIOLATION. After this patch I got 0..3 fails for 100 connections and 0 fails for 50 connections. After closing the copied file probably the system may cache it some time per process. The file may be blocked by the built-in antivirus for some time. It is hard to figure out the exact reason. We have a buildbot to run cross API tests in 8 threads with Linux Aarch64 target. All tests are green with the current (single thread) lldb-server. But we got randomly failed 50..60 tests with the multithreading version of lldb-server. Probably it is just little bit faster and system did not unlock the executable. We noticed that usually failed tests use simple and tiny executables. But this fact does not help to explain the reason of the problem. We got 100% green tests after this patch. 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] 7345025 - [lldb-dap] Updated README.md for newly added attach properties. (#99926)
Author: Santhosh Kumar Ellendula
Date: 2024-07-26T10:22:33-05:00
New Revision: 73450251497f3880ff90d36d2bb43f02dd022239
URL:
https://github.com/llvm/llvm-project/commit/73450251497f3880ff90d36d2bb43f02dd022239
DIFF:
https://github.com/llvm/llvm-project/commit/73450251497f3880ff90d36d2bb43f02dd022239.diff
LOG: [lldb-dap] Updated README.md for newly added attach properties. (#99926)
Added "gdb-remote-port" and "gdb-remote-hostname" attach properties
usage in
README.md and updated package.json version to 0.2.3
This was missed in PR https://github.com/llvm/llvm-project/pull/91570
-
Co-authored-by: Santhosh Kumar Ellendula
Co-authored-by: Santhosh Kumar Ellendula
Added:
Modified:
lldb/tools/lldb-dap/README.md
lldb/tools/lldb-dap/package.json
Removed:
diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 8ecbaf7ce9816..11a14d29ab51e 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -157,6 +157,20 @@ locally on port `2345`.
}
```
+You can also use the `gdb-remote-port` parameter to send an attach request
+to a debug server running on the current machine,
+instead of using the custom command `attachCommands`.
+
+```javascript
+{
+ "name": "Local Debug Server",
+ "type": "lldb-dap",
+ "request": "attach",
+ "program": "/tmp/a.out",
+ "gdb-remote-port": 2345,
+}
+```
+
Connect to a Debug Server on Another Machine
This connects to a debug server running on another machine with hostname
@@ -173,6 +187,23 @@ port `5678` of that other machine.
}
```
+You can also use the `gdb-remote-hostname` and `gdb-remote-port` parameters
+to send an attach request to a debug server running on a
diff erent machine,
+instead of custom command `attachCommands`.
+The default hostname being used `localhost`.
+
+
+```javascript
+{
+ "name": "Local Debug Server",
+ "type": "lldb-dap",
+ "request": "attach",
+ "program": "/tmp/a.out",
+ "gdb-remote-port": 5678,
+ "gdb-remote-hostname": "hostname",
+}
+```
+
## Custom debugger commands
The `lldb-dap` tool includes additional custom commands to support the Debug
diff --git a/lldb/tools/lldb-dap/package.json
b/lldb/tools/lldb-dap/package.json
index fd5de30ed28dd..97e4efe7bac19 100644
--- a/lldb/tools/lldb-dap/package.json
+++ b/lldb/tools/lldb-dap/package.json
@@ -1,7 +1,7 @@
{
"name": "lldb-dap",
"displayName": "LLDB DAP",
- "version": "0.2.2",
+ "version": "0.2.3",
"publisher": "llvm-vs-code-extensions",
"homepage": "https://lldb.llvm.org";,
"description": "LLDB debugging from VSCode",
@@ -353,7 +353,7 @@
"number",
"string"
],
-"description": "TCP/IP port to attach to. Specifying both pid
and port is an error."
+"description": "TCP/IP port to attach to a remote system.
Specifying both pid and port is an error."
},
"gdb-remote-hostname": {
"type": "string",
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Updated README.md for newly added attach properties. (PR #99926)
https://github.com/tedwoodward closed https://github.com/llvm/llvm-project/pull/99926 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][TypeSystemClang][NFC] Clean up TypeSystemClang::GetBitSize (PR #100674)
Michael137 wrote: Test failure is: ``` 2024-07-26 07:38:47 BST Timed Out Tests (1): 2024-07-26 07:38:47 BST lldb-api :: functionalities/fork/concurrent_vfork/TestConcurrentVFork.py ``` Which is unrelated (and I've seen be flakey lately). Will merge now https://github.com/llvm/llvm-project/pull/100674 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 11a7ee5 - [lldb][TypeSystemClang][NFC] Clean up TypeSystemClang::GetBitSize (#100674)
Author: Michael Buch
Date: 2024-07-26T16:47:47+01:00
New Revision: 11a7ee50b400fc13cf772c81e09c153c93665658
URL:
https://github.com/llvm/llvm-project/commit/11a7ee50b400fc13cf772c81e09c153c93665658
DIFF:
https://github.com/llvm/llvm-project/commit/11a7ee50b400fc13cf772c81e09c153c93665658.diff
LOG: [lldb][TypeSystemClang][NFC] Clean up TypeSystemClang::GetBitSize (#100674)
This patch performs following NFC changes to
TypeSystemClang::GetBitSize:
* Factor out the Objective-C logic into a helper function.
* Introduce a new case for `FunctionProto`. I don't see a good reason
for special-casing this in the `default` case.
* We had a redundant check for `GetCompleteType` in the `RecordType`
case. We used to allow zero-size types for records and function
prototypes, so we can just fold them into the same case.
* Introduce a new case for `IncompleteArray`.
The motivation for this is that there are a few issues around VLAs
(i.e., `Type::IncompleteArray`) whose fixes will be easier to reason
about after this refactor.
Generally I don't think treating a type with 0 size as an error is the
right thing to do (at least not for array types). But that's not
something I wanted to fold into this NFC change.
Added:
Modified:
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
Removed:
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index f70efe5ed57e4..0386e3b261c55 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4725,67 +4725,68 @@ TypeSystemClang::GetFloatTypeSemantics(size_t
byte_size) {
return llvm::APFloatBase::Bogus();
}
+std::optional
+TypeSystemClang::GetObjCBitSize(QualType qual_type,
+ExecutionContextScope *exe_scope) {
+ assert(qual_type->isObjCObjectOrInterfaceType());
+ ExecutionContext exe_ctx(exe_scope);
+ if (Process *process = exe_ctx.GetProcessPtr()) {
+if (ObjCLanguageRuntime *objc_runtime =
+ObjCLanguageRuntime::Get(*process)) {
+ if (std::optional bit_size =
+ objc_runtime->GetTypeBitSize(GetType(qual_type)))
+return *bit_size;
+}
+ } else {
+static bool g_printed = false;
+if (!g_printed) {
+ StreamString s;
+ DumpTypeDescription(qual_type.getAsOpaquePtr(), s);
+
+ llvm::outs() << "warning: trying to determine the size of type ";
+ llvm::outs() << s.GetString() << "\n";
+ llvm::outs() << "without a valid ExecutionContext. this is not "
+ "reliable. please file a bug against LLDB.\n";
+ llvm::outs() << "backtrace:\n";
+ llvm::sys::PrintStackTrace(llvm::outs());
+ llvm::outs() << "\n";
+ g_printed = true;
+}
+ }
+
+ return getASTContext().getTypeSize(qual_type) +
+ getASTContext().getTypeSize(getASTContext().ObjCBuiltinClassTy);
+}
+
std::optional
TypeSystemClang::GetBitSize(lldb::opaque_compiler_type_t type,
ExecutionContextScope *exe_scope) {
- if (GetCompleteType(type)) {
-clang::QualType qual_type(GetCanonicalQualType(type));
-const clang::Type::TypeClass type_class = qual_type->getTypeClass();
-switch (type_class) {
-case clang::Type::Record:
- if (GetCompleteType(type))
-return getASTContext().getTypeSize(qual_type);
- else
-return std::nullopt;
- break;
+ if (!GetCompleteType(type))
+return std::nullopt;
-case clang::Type::ObjCInterface:
-case clang::Type::ObjCObject: {
- ExecutionContext exe_ctx(exe_scope);
- Process *process = exe_ctx.GetProcessPtr();
- if (process) {
-if (ObjCLanguageRuntime *objc_runtime =
-ObjCLanguageRuntime::Get(*process)) {
- if (std::optional bit_size =
- objc_runtime->GetTypeBitSize(GetType(qual_type)))
-return *bit_size;
-}
- } else {
-static bool g_printed = false;
-if (!g_printed) {
- StreamString s;
- DumpTypeDescription(type, s);
-
- llvm::outs() << "warning: trying to determine the size of type ";
- llvm::outs() << s.GetString() << "\n";
- llvm::outs() << "without a valid ExecutionContext. this is not "
- "reliable. please file a bug against LLDB.\n";
- llvm::outs() << "backtrace:\n";
- llvm::sys::PrintStackTrace(llvm::outs());
- llvm::outs() << "\n";
- g_printed = true;
-}
- }
-}
- [[fallthrough]];
-default:
- const uint32_t bit_size = getASTContext().getTypeSize(qual_type);
- if (bit_size == 0) {
-if (qual_type->isIncompleteArrayType())
- return getASTContext().getTypeSize(
- qual_type
[Lldb-commits] [lldb] [lldb][TypeSystemClang][NFC] Clean up TypeSystemClang::GetBitSize (PR #100674)
https://github.com/Michael137 closed https://github.com/llvm/llvm-project/pull/100674 ___ 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/tedwoodward 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][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/100710
>From 59f8a161ec1ccb4c5b13c6760f652f574a4b435d Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 26 Jul 2024 01:58:54 +0100
Subject: [PATCH 1/2] [lldb][TypeSystemClang] Don't create VLAs of explicitly
0-size as IncompleteArrayTypes
---
lldb/include/lldb/Symbol/SymbolFile.h | 2 +-
.../SymbolFile/DWARF/DWARFASTParser.cpp | 5 +-
.../SymbolFile/DWARF/DWARFASTParserClang.cpp | 12 +--
.../TypeSystem/Clang/TypeSystemClang.cpp | 50 ++--
.../TypeSystem/Clang/TypeSystemClang.h| 3 +-
lldb/test/API/lang/c/struct_types/main.c | 3 +-
lldb/test/Shell/SymbolFile/DWARF/vla.cpp | 80 +++
7 files changed, 120 insertions(+), 35 deletions(-)
create mode 100644 lldb/test/Shell/SymbolFile/DWARF/vla.cpp
diff --git a/lldb/include/lldb/Symbol/SymbolFile.h
b/lldb/include/lldb/Symbol/SymbolFile.h
index d20766788192f..a050a04a5573b 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -211,7 +211,7 @@ class SymbolFile : public PluginInterface {
/// The characteristics of an array type.
struct ArrayInfo {
int64_t first_index = 0;
-llvm::SmallVector element_orders;
+llvm::SmallVector, 1> element_orders;
uint32_t byte_stride = 0;
uint32_t bit_stride = 0;
};
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
index 409e9bb37ab28..b3d231604aa44 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
@@ -37,7 +37,7 @@ DWARFASTParser::ParseChildArrayInfo(const DWARFDIE
&parent_die,
if (attributes.Size() == 0)
continue;
-uint64_t num_elements = 0;
+std::optional num_elements;
uint64_t lower_bound = 0;
uint64_t upper_bound = 0;
bool upper_bound_valid = false;
@@ -66,6 +66,7 @@ DWARFASTParser::ParseChildArrayInfo(const DWARFDIE
&parent_die,
}
} else
num_elements = form_value.Unsigned();
+
break;
case DW_AT_bit_stride:
@@ -91,7 +92,7 @@ DWARFASTParser::ParseChildArrayInfo(const DWARFDIE
&parent_die,
}
}
-if (num_elements == 0) {
+if (!num_elements || *num_elements == 0) {
if (upper_bound_valid && upper_bound >= lower_bound)
num_elements = upper_bound - lower_bound + 1;
}
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 85c59a605c675..a4dcde1629fc2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -1395,20 +1395,20 @@ DWARFASTParserClang::ParseArrayType(const DWARFDIE &die,
uint64_t array_element_bit_stride = byte_stride * 8 + bit_stride;
CompilerType clang_type;
if (array_info && array_info->element_orders.size() > 0) {
-uint64_t num_elements = 0;
auto end = array_info->element_orders.rend();
for (auto pos = array_info->element_orders.rbegin(); pos != end; ++pos) {
- num_elements = *pos;
- clang_type = m_ast.CreateArrayType(array_element_type, num_elements,
- attrs.is_vector);
+ clang_type = m_ast.CreateArrayType(
+ array_element_type, /*element_count=*/*pos, attrs.is_vector);
+
+ uint64_t num_elements = pos->value_or(0);
array_element_type = clang_type;
array_element_bit_stride = num_elements
? array_element_bit_stride * num_elements
: array_element_bit_stride;
}
} else {
-clang_type =
-m_ast.CreateArrayType(array_element_type, 0, attrs.is_vector);
+clang_type = m_ast.CreateArrayType(
+array_element_type, /*element_count=*/std::nullopt, attrs.is_vector);
}
ConstString empty_name;
TypeSP type_sp =
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 0386e3b261c55..484ca04fe04c9 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2233,30 +2233,31 @@ TypeSystemClang::CreateBlockPointerType(const
CompilerType &function_type) {
#pragma mark Array Types
-CompilerType TypeSystemClang::CreateArrayType(const CompilerType &element_type,
- size_t element_count,
- bool is_vector) {
- if (element_type.IsValid()) {
-ASTContext &ast = getASTContext();
+CompilerType
+TypeSystemClang::CreateArrayType(const CompilerType &element_type,
+ std::optional element_count,
+ bool is_vector) {
+ if (!elem
[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/100710 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove python helper getCompilerBinary() (PR #100660)
https://github.com/JDevlieghere approved this pull request. 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] Refactor TypeQuery::ContextMatches (PR #99305)
https://github.com/clayborg commented:
My main questions is do we actually use wildcards a lot? In normal type query
matches, we can ask for exact matches where everything is specified, or the
user types some string like `a::b::iterator` where we don't know what any of
the items are. If exact match is specified then all levels need to match the
type we found, but if exact match is not specified, then we accept anything
that ends with the specified compiler context. There are no wildcards specified
in any of these kinds of queries from a type lookup perspective right? Where
are these actual wildcard searches happening?
When searching for a type in anonymous namespaces, are you expecting the
compiler context that gets created for such types is doing to include the
anonymous namespace in the context? So for:
```
namespace {
struct Foo {};
}
```
The compiler context will end up being:
```
namespace ""
struct "Foo"
```
We might need to notion of a declaration context barrier item in our
CompilerContext arrays that say "the type below this is fully qualified on its
own, but this barrier can help disambiguate searches if the user fully
specifies things. For example a type in a function right now:
```
namespace a {
void func1() {
namespace b {
struct foo{};
};
}
```
Currently will produce a compiler contenxt of:
```
namespace "b"
struct "foo"
```
But could it could include "func1"'s context in the future:
```
namespace "a"
function "func1" barrier entry (for lack of a better term)
namespace "b"
struct "foo"
```
Then a search for an exact type name `"b::foo"` could match the above compiler
context as it matches fully up to a barrier `CompilerContext`. But if the users
knows they want this exact type they could ask for `"a::func1::b::foo"` and get
the right one if they were other `"b::foo"` types.
I mention this because for anonynmous namespace types, we might not want to
have to type `"(anonymous namespace)::Foo"` to find the type from my first
example, users probably just want to type `"Foo"` and still find the type and
the anonymous namespace could be one of these new decl context root barriers.
Any clarification on what you plan to do for anonymous types would be great to
hear.
https://github.com/llvm/llvm-project/pull/99305
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Remove the redundent increment of 'properties' variable (PR #95675)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/95675 ___ 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:
I am fine with the change, makes sense.
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:
Makes sense.
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)
https://github.com/clayborg commented: All changes look good as is, just one inline question about maybe not setting the error if we detect the .dwo files are both empty (if it is possible to do). 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)
https://github.com/clayborg edited 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)
@@ -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));
clayborg wrote:
Can we detect these empty .dwo files and not warn if they contain no data?
Detection would probably need to be done in `LinkToSkeletonUnit(...)` and it
can return true if it detects two .dwo files being linked that are both empty?
Not sure if this will help stop errors from being displayed in cases where it
doesn't matter?
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][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 4e8dec03681b223fa7eec05c8a5a49ef11165b18 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..629ccee32e840 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] Remove python helper getCompilerBinary() (PR #100660)
kendalharland wrote: > Seems fine to me, but there is a use of it in > `lldb/packages/Python/lldbsuite/test/lldbtest.py` that should also be removed. Not sure how I missed that one. Ty! 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] Remove python helper getCompilerBinary() (PR #100660)
https://github.com/kendalharland updated
https://github.com/llvm/llvm-project/pull/100660
>From 6769752234f67ac693ea7345393fd9d72fa4a567 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
---
.../packages/Python/lldbsuite/test/lldbplatformutil.py | 10 +++---
lldb/packages/Python/lldbsuite/test/lldbtest.py| 4
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index e3c6fd1a99568..602e15d207e94 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -266,17 +266,13 @@ 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()
-version_output = subprocess.check_output([compiler, "--version"],
errors="replace")
+version_output = subprocess.check_output(
+[getCompiler(), "--version"], errors="replace"
+)
m = re.search("version ([0-9.]+)", version_output)
if m:
return m.group(1)
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 5e50b0c145885..f97c41d867e78 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1379,10 +1379,6 @@ def getCompiler(self):
"""Returns the compiler in effect the test suite is running with."""
return lldbplatformutil.getCompiler()
-def getCompilerBinary(self):
-"""Returns the compiler binary the test suite is running with."""
-return lldbplatformutil.getCompilerBinary()
-
def getCompilerVersion(self):
"""Returns a string that represents the compiler version.
Supports: llvm, clang.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove python helper getCompilerBinary() (PR #100660)
kendalharland wrote: Thanks for the reviews! I'll need help merging from someone with write access 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][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: Removed `-stdlib=libstdc++`. The problem was, that we were trying to link with in-tree libcxx not linked statically to libcxxabi, but clang driver couldn't use it without the explicit -lc++abi flag (it doesn't distinguish libcxx comilation types according to https://releases.llvm.org/6.0.0/projects/libcxx/docs/BuildingLibcxx.html#using-libcxxrt-on-linux). Adding LIBCXX_ENABLE_STATIC_ABI_LIBRARY helps. 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)
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)
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] 3e593b9 - [lldb] Remove python helper getCompilerBinary() (#100660)
Author: Kendal Harland
Date: 2024-07-26T10:43:58-07:00
New Revision: 3e593b9b3b86ebf28e24c3a33791be49e0735af5
URL:
https://github.com/llvm/llvm-project/commit/3e593b9b3b86ebf28e24c3a33791be49e0735af5
DIFF:
https://github.com/llvm/llvm-project/commit/3e593b9b3b86ebf28e24c3a33791be49e0735af5.diff
LOG: [lldb] Remove python helper getCompilerBinary() (#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 the absolute path to Visual studio's installation directory.
Co-authored-by: kendal
Added:
Modified:
lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
lldb/packages/Python/lldbsuite/test/lldbtest.py
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index e3c6fd1a99568..602e15d207e94 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -266,17 +266,13 @@ 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()
-version_output = subprocess.check_output([compiler, "--version"],
errors="replace")
+version_output = subprocess.check_output(
+[getCompiler(), "--version"], errors="replace"
+)
m = re.search("version ([0-9.]+)", version_output)
if m:
return m.group(1)
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 5e50b0c145885..f97c41d867e78 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1379,10 +1379,6 @@ def getCompiler(self):
"""Returns the compiler in effect the test suite is running with."""
return lldbplatformutil.getCompiler()
-def getCompilerBinary(self):
-"""Returns the compiler binary the test suite is running with."""
-return lldbplatformutil.getCompilerBinary()
-
def getCompilerVersion(self):
"""Returns a string that represents the compiler version.
Supports: llvm, clang.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove python helper getCompilerBinary() (PR #100660)
https://github.com/JDevlieghere closed 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][test][x86_64][win] Set breakpoint condition on breakpoint instead of location in TestBreakpointConditions (PR #100487)
https://github.com/kendalharland updated
https://github.com/llvm/llvm-project/pull/100487
>From 29d5a57eb8cc344e1a93787fe9cb333761923927 Mon Sep 17 00:00:00 2001
From: kendal
Date: Tue, 23 Jul 2024 10:24:24 -0700
Subject: [PATCH] [lldb][test][x86_64][win] Split TestBreakpointConditions
assertion to clarify failure message
When this test fails we see an assertion error `False != True`
This clarifies the error by showing, for example, if `1 != 3` when
comparing `var` to the string "3".
---
.../breakpoint_conditions/TestBreakpointConditions.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
a/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
b/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
index 50ba0317fd094..4e7a8ccb9fbeb 100644
---
a/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
+++
b/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
@@ -176,11 +176,15 @@ def breakpoint_conditions_python(self):
thread.IsValid(),
"There should be a thread stopped due to breakpoint condition",
)
+
frame0 = thread.GetFrameAtIndex(0)
var = frame0.FindValue("val", lldb.eValueTypeVariableArgument)
-self.assertTrue(
-frame0.GetLineEntry().GetLine() == self.line1 and var.GetValue()
== "3"
+self.assertEqual(
+frame0.GetLineEntry().GetLine(),
+self.line1,
+"The debugger stopped on the correct line",
)
+self.assertEqual(var.GetValue(), "3")
# The hit count for the breakpoint should be 1.
self.assertEqual(breakpoint.GetHitCount(), 1)
___
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)
https://github.com/kendalharland edited 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][test][x86_64][win] Set breakpoint condition on breakpoint instead of location in TestBreakpointConditions (PR #100487)
kendalharland wrote: > The only way that this could succeed on the breakpoint but fail on the > location is that there is more than one location and the one the test is > 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. Thanks for the context! In this PR I learned that the set of compilers I was using to build LLVM are different from the existing lldb-aarch64-windows builder. After fixing that, I am no longer seeing this test fail. I've removed the top commit and left only the one that splits the test assertion to produce a more clear failure message. 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][test][x86_64][win] Split assertion TestBreakpointConditions (PR #100487)
https://github.com/kendalharland edited 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][test][x86_64][win] Split assertion in TestBreakpointConditions (PR #100487)
https://github.com/kendalharland edited 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][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
@@ -52,6 +52,7 @@ def test_negative_indexing(self): self.build() self.validate_negative_indexing() +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) kendalharland wrote: Thanks! I'll try that and update 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] Fix XFAIL and XPASS on LLDB API tests (PR #100477)
@@ -12,6 +12,7 @@ class MultipleSlidesTestCase(TestBase): NO_DEBUG_INFO_TESTCASE = True +@expectedFailureAll(oslist=["windows"], archs=["x86_64"]) kendalharland wrote: Ty! I'll try that out. 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][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -6621,29 +6624,28 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
LC_THREAD_data.SetAddressByteSize(addr_byte_size);
LC_THREAD_data.SetByteOrder(byte_order);
}
-for (uint32_t thread_idx = 0; thread_idx < num_threads; ++thread_idx) {
- ThreadSP thread_sp(thread_list.GetThreadAtIndex(thread_idx));
+for (const ThreadSP &thread_sp : thread_list) {
if (thread_sp) {
switch (mach_header.cputype) {
case llvm::MachO::CPU_TYPE_ARM64:
case llvm::MachO::CPU_TYPE_ARM64_32:
RegisterContextDarwin_arm64_Mach::Create_LC_THREAD(
- thread_sp.get(), LC_THREAD_datas[thread_idx]);
+ thread_sp.get(), LC_THREAD_datas[thread_sp->GetIndexID()]);
clayborg wrote:
We can't use `thread_sp->GetIndexID()` here, as before this was the index of
the thread from `thread_list`, not the thread's index ID. Why? Because thread
index IDs are unique for a process. If you have a process which starts with one
thread, its index ID is 1. If this process creates a thread and we stop when
this thread is created, we will create a new thread for it and its index ID
will be 2. Then this thread exits and a new thread is created and we stop. We
will now have two threads whose index IDs are 1 and 3. So we can't use this
index as a zero based index into the LC_THREAD_datas array.
So we might need to still use a `thread_idx` in this for loop. See above.
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -53,6 +54,27 @@ class LLDB_API SBSaveCoreOptions {
/// \return The output file spec.
SBFileSpec GetOutputFile() const;
+ /// Set the process to save, or unset if supplied with a null process.
+ ///
+ /// \param process The process to save.
+ /// \return Success if process was set, otherwise an error
+ /// \note This will clear all process specific options if
+ /// an exisiting process is overriden.
clayborg wrote:
These lines should go up to column 79, these lines are stopping at column 60.
Re-wrap.
Maybe reword a bit:
```
/// \note This will clear all process specific options if a different process
/// is specified from a previous call to this function or to any other
/// functions that set the process.
```
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
clayborg wrote:
```
m_process_sp.reset();
```
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -6668,6 +6676,18 @@ Status
Process::CalculateCoreFileSaveRanges(lldb::SaveCoreStyle core_style,
return Status(); // Success!
}
+std::vector
+Process::CalculateCoreFileThreadList(const SaveCoreOptions &core_options) {
+ std::vector thread_list;
+ for (const auto &thread : m_thread_list.Threads()) {
clayborg wrote:
change `const auto &thread ` to `const ThreadSP &thread_sp` to indicate
"thread" is a shared pointer and not use `auto` unless it saves tons of text
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if (!process_sp->IsValid()) {
+error.SetErrorString("Cannot assign an invalid process.");
+return error;
+ }
+
+ if (m_process_sp)
+ClearProcessSpecificData();
+
+ m_process_sp = process_sp;
+ return error;
+}
+
+Status SaveCoreOptions::AddThread(lldb::ThreadSP thread_sp) {
+ Status error;
+ if (!thread_sp) {
+error.SetErrorString("Thread is null");
+return error;
+ }
+
+ if (m_process_sp) {
+if (m_process_sp != thread_sp->GetProcess()) {
+ error.SetErrorString("Cannot add a thread from a different process.");
+ return error;
+}
+ } else {
+m_process_sp = thread_sp->GetProcess();
+ }
+
+ m_threads_to_save[thread_sp->GetID()];
+ return error;
+}
+
+bool SaveCoreOptions::RemoveThread(lldb::ThreadSP thread_sp) {
+ return thread_sp && m_threads_to_save.erase(thread_sp->GetID()) > 0;
+}
+
+bool SaveCoreOptions::ShouldThreadBeSaved(lldb::tid_t tid) const {
+ // If the user specified no threads to save, then we save all threads.
+ if (m_threads_to_save.empty())
+return true;
+ return m_threads_to_save.count(tid) > 0;
+}
+
+Status SaveCoreOptions::EnsureValidConfiguration(
+lldb::ProcessSP process_to_save) const {
+ Status error;
+ std::string error_str;
+ if (!m_threads_to_save.empty() && GetStyle() == lldb::eSaveCoreFull)
+error_str += "Cannot save a full core with a subset of threads\n";
+
+ if (m_process_sp && m_process_sp != process_to_save)
+error_str += "Cannot save core for process using supplied core options. "
+ "Options were constructed targeting a different process. \n";
+
+ if (!error_str.empty())
+error.SetErrorString(error_str);
+
+ return error;
+}
+
+void SaveCoreOptions::ClearProcessSpecificData() { m_threads_to_save.clear(); }
+
void SaveCoreOptions::Clear() {
m_file = std::nullopt;
m_plugin_name = std::nullopt;
m_style = std::nullopt;
clayborg wrote:
Add:
```
m_process_sp.reset();
```
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -6729,8 +6731,7 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
std::make_shared());
StructuredData::ArraySP threads(
std::make_shared());
-for (uint32_t thread_idx = 0; thread_idx < num_threads; ++thread_idx) {
- ThreadSP thread_sp(thread_list.GetThreadAtIndex(thread_idx));
+for (const ThreadSP &thread_sp : thread_list) {
clayborg wrote:
If nothing inside this loop need the zero based `thread_idx` we can leave this
one
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -53,6 +54,27 @@ class LLDB_API SBSaveCoreOptions {
/// \return The output file spec.
SBFileSpec GetOutputFile() const;
+ /// Set the process to save, or unset if supplied with a null process.
clayborg wrote:
change `null process` to a `default constructed SBProcess`... though Maybe we
should require a valid process here and add a `void ClearProcess()` API to have
this make more sense.
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -6621,29 +6624,28 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
LC_THREAD_data.SetAddressByteSize(addr_byte_size);
LC_THREAD_data.SetByteOrder(byte_order);
}
-for (uint32_t thread_idx = 0; thread_idx < num_threads; ++thread_idx) {
- ThreadSP thread_sp(thread_list.GetThreadAtIndex(thread_idx));
clayborg wrote:
we need to revert this change back as we need a zero based thread index into
`LC_THREAD_datas`:
```
for (uint32_t thread_idx = 0; thread_idx < num_threads; ++thread_idx) {
ThreadSP thread_sp = thread_list[thread_idx];
```
We don't want to use `for (const ThreadSP &thread_sp : thread_list) {` anymore
because we need the index for the `thread_sp` within `thread_list`
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if (!process_sp->IsValid()) {
+error.SetErrorString("Cannot assign an invalid process.");
+return error;
+ }
+
+ if (m_process_sp)
+ClearProcessSpecificData();
+
+ m_process_sp = process_sp;
+ return error;
+}
+
+Status SaveCoreOptions::AddThread(lldb::ThreadSP thread_sp) {
+ Status error;
+ if (!thread_sp) {
+error.SetErrorString("Thread is null");
clayborg wrote:
```
error.SetErrorString("invalid thread");
```
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if (!process_sp->IsValid()) {
+error.SetErrorString("Cannot assign an invalid process.");
+return error;
+ }
+
+ if (m_process_sp)
+ClearProcessSpecificData();
clayborg wrote:
You already checked `m_process_sp` above, this can just be:
```
ClearProcessSpecificData();
```
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] [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (PR #100443)
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if (!process_sp->IsValid()) {
+error.SetErrorString("Cannot assign an invalid process.");
+return error;
+ }
+
clayborg wrote:
Don't clear the process specific data if we set the process to the same process:
```
// Don't clear any process specific data if the process is the same.
if (process_sp == m_process_sp)
return error;
```
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
