[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/137974
This fixes a regression caused by us starting to parse types from declarations.
The code in TypeSystemClang was assuming that the value held in
ClangASTMetadata was authoritative, but this isn't (and cannot) be the case
when the type is parsed from a forward-declaration.
For the fix, I add a new "don't know" state to ClangASTMetadata, and make sure
DWARFASTParserClang sets it only when it encounters a forward declaration. In
this case, the type system will fall back to completing the type.
This does mean that we will be completing more types than before, but I'm
hoping this will offset by the fact that we don't search for definition DIEs
eagerly. In particular, I don't make a difference in -fstandalone-debug
scenarios, since types will nearly always be present as definitions.
To avoid this cost, we'd need to create some sort of a back channel to query
the DWARFASTParser about the dynamicness of the type without actually
completing it. I'd like to avoid that if it is not necessary.
>From 78d25e30f56af996278730cd4b4db99401552d6f Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Wed, 30 Apr 2025 16:23:39 +0200
Subject: [PATCH] [lldb] Fix dynamic type resolution for types parsed from
declarations
This fixes a regression caused by us starting to parse types from
declarations. The code in TypeSystemClang was assuming that the value
held in ClangASTMetadata was authoritative, but this isn't (and cannot)
be the case when the type is parsed from a forward-declaration.
For the fix, I add a new "don't know" state to ClangASTMetadata, and
make sure DWARFASTParserClang sets it only when it encounters a forward
declaration. In this case, the type system will fall back to
completing the type.
This does mean that we will be completing more types than before, but
I'm hoping this will offset by the fact that we don't search for
definition DIEs eagerly. In particular, I don't make a difference in
-fstandalone-debug scenarios, since types will nearly always be present
as definitions.
To avoid this cost, we'd need to create some sort of a back channel to
query the DWARFASTParser about the dynamicness of the type without
actually completing it. I'd like to avoid that if it is not necessary.
---
.../Clang/ClangASTMetadata.cpp | 16
.../ExpressionParser/Clang/ClangASTMetadata.h | 15 +--
.../SymbolFile/DWARF/DWARFASTParserClang.cpp | 3 ++-
.../TypeSystem/Clang/TypeSystemClang.cpp | 18 +++---
lldb/test/API/lang/cpp/dynamic-value/Makefile | 2 +-
.../lang/cpp/dynamic-value/TestDynamicValue.py | 12
lldb/test/API/lang/cpp/dynamic-value/a.h | 2 ++
.../API/lang/cpp/dynamic-value/forward-a.cpp | 3 +++
.../lang/cpp/dynamic-value/pass-to-base.cpp| 2 ++
9 files changed, 58 insertions(+), 15 deletions(-)
create mode 100644 lldb/test/API/lang/cpp/dynamic-value/forward-a.cpp
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
index 42933c78b0277..2c5dacb60a9b8 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
@@ -11,6 +11,22 @@
using namespace lldb_private;
+std::optional ClangASTMetadata::GetIsDynamicCXXType() const {
+ switch (m_is_dynamic_cxx) {
+ case 0:
+return std::nullopt;
+ case 1:
+return false;
+ case 2:
+return true;
+ }
+ llvm_unreachable("Invalid m_is_dynamic_cxx value");
+}
+
+void ClangASTMetadata::SetIsDynamicCXXType(std::optional b) {
+ m_is_dynamic_cxx = b ? *b + 1 : 0;
+}
+
void ClangASTMetadata::Dump(Stream *s) {
lldb::user_id_t uid = GetUserID();
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
index d3bcde2ced799..ecaa2e0ddf97c 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
@@ -12,6 +12,7 @@
#include "lldb/Core/dwarf.h"
#include "lldb/lldb-defines.h"
#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-private-enumerations.h"
namespace lldb_private {
@@ -19,12 +20,14 @@ class ClangASTMetadata {
public:
ClangASTMetadata()
: m_user_id(0), m_union_is_user_id(false), m_union_is_isa_ptr(false),
-m_has_object_ptr(false), m_is_self(false), m_is_dynamic_cxx(true),
-m_is_forcefully_completed(false) {}
+m_has_object_ptr(false), m_is_self(false),
+m_is_forcefully_completed(false) {
+SetIsDynamicCXXType(std::nullopt);
+ }
- bool GetIsDynamicCXXType() const { return m_is_dynamic_cxx; }
+ std::optional GetIsDynamicCXXType() const;
- void SetIsDynamicCXXType(bool b) { m_is_dynamic_cxx = b; }
+ void SetIsDynamicCXXType(std::optional b);
void SetUserID(lldb::u
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
This fixes a regression caused by us starting to parse types from declarations.
The code in TypeSystemClang was assuming that the value held in
ClangASTMetadata was authoritative, but this isn't (and cannot) be the case
when the type is parsed from a forward-declaration.
For the fix, I add a new "don't know" state to ClangASTMetadata, and make sure
DWARFASTParserClang sets it only when it encounters a forward declaration. In
this case, the type system will fall back to completing the type.
This does mean that we will be completing more types than before, but I'm
hoping this will offset by the fact that we don't search for definition DIEs
eagerly. In particular, I don't make a difference in -fstandalone-debug
scenarios, since types will nearly always be present as definitions.
To avoid this cost, we'd need to create some sort of a back channel to query
the DWARFASTParser about the dynamicness of the type without actually
completing it. I'd like to avoid that if it is not necessary.
---
Full diff: https://github.com/llvm/llvm-project/pull/137974.diff
9 Files Affected:
- (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
(+16)
- (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
(+9-6)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(+2-1)
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+11-7)
- (modified) lldb/test/API/lang/cpp/dynamic-value/Makefile (+1-1)
- (modified) lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py (+12)
- (modified) lldb/test/API/lang/cpp/dynamic-value/a.h (+2)
- (added) lldb/test/API/lang/cpp/dynamic-value/forward-a.cpp (+3)
- (modified) lldb/test/API/lang/cpp/dynamic-value/pass-to-base.cpp (+2)
``diff
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
index 42933c78b0277..2c5dacb60a9b8 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.cpp
@@ -11,6 +11,22 @@
using namespace lldb_private;
+std::optional ClangASTMetadata::GetIsDynamicCXXType() const {
+ switch (m_is_dynamic_cxx) {
+ case 0:
+return std::nullopt;
+ case 1:
+return false;
+ case 2:
+return true;
+ }
+ llvm_unreachable("Invalid m_is_dynamic_cxx value");
+}
+
+void ClangASTMetadata::SetIsDynamicCXXType(std::optional b) {
+ m_is_dynamic_cxx = b ? *b + 1 : 0;
+}
+
void ClangASTMetadata::Dump(Stream *s) {
lldb::user_id_t uid = GetUserID();
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
index d3bcde2ced799..ecaa2e0ddf97c 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTMetadata.h
@@ -12,6 +12,7 @@
#include "lldb/Core/dwarf.h"
#include "lldb/lldb-defines.h"
#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-private-enumerations.h"
namespace lldb_private {
@@ -19,12 +20,14 @@ class ClangASTMetadata {
public:
ClangASTMetadata()
: m_user_id(0), m_union_is_user_id(false), m_union_is_isa_ptr(false),
-m_has_object_ptr(false), m_is_self(false), m_is_dynamic_cxx(true),
-m_is_forcefully_completed(false) {}
+m_has_object_ptr(false), m_is_self(false),
+m_is_forcefully_completed(false) {
+SetIsDynamicCXXType(std::nullopt);
+ }
- bool GetIsDynamicCXXType() const { return m_is_dynamic_cxx; }
+ std::optional GetIsDynamicCXXType() const;
- void SetIsDynamicCXXType(bool b) { m_is_dynamic_cxx = b; }
+ void SetIsDynamicCXXType(std::optional b);
void SetUserID(lldb::user_id_t user_id) {
m_user_id = user_id;
@@ -101,8 +104,8 @@ class ClangASTMetadata {
uint64_t m_isa_ptr;
};
- bool m_union_is_user_id : 1, m_union_is_isa_ptr : 1, m_has_object_ptr : 1,
- m_is_self : 1, m_is_dynamic_cxx : 1, m_is_forcefully_completed : 1;
+ unsigned m_union_is_user_id : 1, m_union_is_isa_ptr : 1, m_has_object_ptr :
1,
+ m_is_self : 1, m_is_dynamic_cxx : 2, m_is_forcefully_completed : 1;
};
} // namespace lldb_private
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index f22fcbab557a0..a3e809f44ed23 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -1837,7 +1837,8 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
ClangASTMetadata metadata;
metadata.SetUserID(die.GetID());
- metadata.SetIsDynamicCXXType(dwarf->ClassOrStructIsVirtual(die));
+ if (!attrs.is_forward_declaration)
+metadata.SetIsDynamicCXXType(dwarf->ClassOrStructIsVirtual(die));
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
github-actions[bot] wrote: :warning: Python code formatter, darker found issues in your code. :warning: You can test this locally with the following command: ``bash darker --check --diff -r HEAD~1...HEAD lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py `` View the diff from darker here. ``diff --- TestDynamicValue.py 2025-04-30 14:48:42.00 + +++ TestDynamicValue.py 2025-04-30 14:55:30.927601 + @@ -274,7 +274,7 @@ a definition of A from somewhere else.""" self.build() lldbutil.run_to_name_breakpoint(self, "take_A") self.expect( "frame var -d run-target --ptr-depth=1 --show-types a", -substrs = ["(B *) a", "m_b_value = 10"], -) +substrs=["(B *) a", "m_b_value = 10"], +) `` https://github.com/llvm/llvm-project/pull/137974 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/126935
>From 2b1621480cde0afd15c30e159d87a7b74013c493 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Sun, 20 Oct 2024 02:55:02 +0200
Subject: [PATCH] [lldb/Host] Enable inheriting "non-inheritable" FDs
Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in
the (few) cases where we need to pass an FD to a subprocess. The problem
with these is that, in a multithreaded application such as lldb, there's
essentially no way to prevent them from being leaked into processes
other than the intended one.
A safer (though still not completely safe) approach is to mark the
descriptors as FD_CLOEXEC and only clear this flag in the subprocess. We
currently have something that almost does that, which is the ability to
add a `DuplicateFileAction` to our `ProcessLaunchInfo` struct (the
duplicated file descriptor will be created with the flag cleared). The
problem with *that* is that this approach is completely incompatible
with Windows.
Windows equivalents of file descriptors are `HANDLE`s, but these do not
have user controlled values -- applications are expected to work with
whatever HANDLE values are assigned by the OS. In unix terms, there is
no equivalent to the `dup2` syscall (only `dup`).
To find a way out of this conundrum, and create a miniscule API surface
that works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto
itself. Currently, this operation does nothing (it leaves the FD_CLOEXEC
flag set), because that's how `dup2(fd, fd)` behaves, but I think it's
not completely unreasonable to say that this operation should clear the
FD_CLOEXEC flag, just like it would do if one was using different fd
values. This would enable us to pass a windows HANDLE as itself through
the ProcessLaunchInfo API.
This PR implements the unix portion of this idea. Macos and non-macos
launchers are updated to clear FD_CLOEXEC flag when duplicating a file
descriptor onto itself, and I've created a test which enables passing a
FD_CLOEXEC file descritor to the subprocess. For the windows portion,
please see the follow-up PR.
---
lldb/source/Host/macosx/objcxx/Host.mm| 11 -
.../Host/posix/ProcessLauncherPosixFork.cpp | 11 -
lldb/unittests/Host/HostTest.cpp | 46 +--
3 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
else if (info->GetActionArgument() == -1)
error = Status::FromErrorString(
"invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
error =
Status(::posix_spawn_file_actions_adddup2(file_actions,
info->GetFD(),
info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
"error: {0}, posix_spawn_file_actions_adddup2 "
"(action={1}, fd={2}, dup_fd={3})",
error, file_actions, info->GetFD(),
info->GetActionArgument());
+} else {
+ error =
+ Status(::posix_spawn_file_actions_addinherit_np(file_actions,
info->GetFD()),
+ eErrorTypePOSIX);
+ if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
}
break;
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 8c6d503fc7fe2..698524349e16a 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -17,6 +17,7 @@
#include "llvm/Support/Errno.h"
#include
+#include
#include
#include
#include
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+if (dup2(action.fd, action.arg) == -1)
+ ExitWithError(error_fd, "dup2");
+ } else {
+if (fcntl(action.fd, F_SETFD,
+ fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
+ ExitWithError(error_fd, "fcntl");
+ }
break;
case FileAction::eFileActionOpen:
DupDescriptor(error_fd, action.path.c_str(), action.fd, action.arg);
diff --git a/lldb/unittests/Host/HostTest
[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in the
(few) cases where we need to pass an FD to a subprocess. The problem with these
is that, in a multithreaded application such as lldb, there's essentially no
way to prevent them from being leaked into processes other than the intended
one.
A safer (though still not completely safe) approach is to mark the descriptors
as FD_CLOEXEC and only clear this flag in the subprocess. We currently have
something that almost does that, which is the ability to add a
`DuplicateFileAction` to our `ProcessLaunchInfo` struct (the duplicated file
descriptor will be created with the flag cleared). The problem with *that* is
that this approach is completely incompatible with Windows.
Windows equivalents of file descriptors are `HANDLE`s, but these do not have
user controlled values -- applications are expected to work with whatever
HANDLE values are assigned by the OS. In unix terms, there is no equivalent to
the `dup2` syscall (only `dup`).
To find a way out of this conundrum, and create a miniscule API surface that
works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto itself.
Currently, this operation does nothing (it leaves the FD_CLOEXEC flag set),
because that's how `dup2(fd, fd)` behaves, but I think it's not completely
unreasonable to say that this operation should clear the FD_CLOEXEC flag, just
like it would do if one was using different fd values. This would enable us to
pass a windows HANDLE as itself through the ProcessLaunchInfo API.
This PR implements the unix portion of this idea. Macos and non-macos launchers
are updated to clear FD_CLOEXEC flag when duplicating a file descriptor onto
itself, and I've created a test which enables passing a FD_CLOEXEC file
descritor to the subprocess. For the windows portion, please see the follow-up
PR.
---
Full diff: https://github.com/llvm/llvm-project/pull/126935.diff
3 Files Affected:
- (modified) lldb/source/Host/macosx/objcxx/Host.mm (+10-1)
- (modified) lldb/source/Host/posix/ProcessLauncherPosixFork.cpp (+9-2)
- (modified) lldb/unittests/Host/HostTest.cpp (+40)
``diff
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
else if (info->GetActionArgument() == -1)
error = Status::FromErrorString(
"invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
error =
Status(::posix_spawn_file_actions_adddup2(file_actions,
info->GetFD(),
info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
"error: {0}, posix_spawn_file_actions_adddup2 "
"(action={1}, fd={2}, dup_fd={3})",
error, file_actions, info->GetFD(),
info->GetActionArgument());
+} else {
+ error =
+ Status(::posix_spawn_file_actions_addinherit_np(file_actions,
info->GetFD()),
+ eErrorTypePOSIX);
+ if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
}
break;
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 8c6d503fc7fe2..698524349e16a 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -17,6 +17,7 @@
#include "llvm/Support/Errno.h"
#include
+#include
#include
#include
#include
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+if (dup2(action.fd, action.arg) == -1)
+ ExitWithError(error_fd, "dup2");
+ } else {
+if (fcntl(action.fd, F_SETFD,
+ fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
+ ExitWithError(error_fd, "fcntl");
+ }
break;
case FileAction::eFileActionOpen:
DupDescriptor(error_fd, action.path.c_str(), action.fd, action.arg);
diff --git a/lldb/unittests/Host/HostTest.cpp b/lldb/unittests/Host/HostTest.cpp
index ed1df6de001ea..222de62ab6697 100644
--- a/lldb/unittests/Host/HostTest.cpp
+++
[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)
https://github.com/labath ready_for_review https://github.com/llvm/llvm-project/pull/126935 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/126935
>From 5b2721cee30a6c8b43efacb43b35c3a3150e6414 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Sun, 20 Oct 2024 02:55:02 +0200
Subject: [PATCH] [lldb/Host] Enable inheriting "non-inheritable" FDs
Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in
the (few) cases where we need to pass an FD to a subprocess. The problem
with these is that, in a multithreaded application such as lldb, there's
essentially no way to prevent them from being leaked into processes
other than the intended one.
A safer (though still not completely safe) approach is to mark the
descriptors as FD_CLOEXEC and only clear this flag in the subprocess. We
currently have something that almost does that, which is the ability to
add a `DuplicateFileAction` to our `ProcessLaunchInfo` struct (the
duplicated file descriptor will be created with the flag cleared). The
problem with *that* is that this approach is completely incompatible
with Windows.
Windows equivalents of file descriptors are `HANDLE`s, but these do not
have user controlled values -- applications are expected to work with
whatever HANDLE values are assigned by the OS. In unix terms, there is
no equivalent to the `dup2` syscall (only `dup`).
To find a way out of this conundrum, and create a miniscule API surface
that works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto
itself. Currently, this operation does nothing (it leaves the FD_CLOEXEC
flag set), because that's how `dup2(fd, fd)` behaves, but I think it's
not completely unreasonable to say that this operation should clear the
FD_CLOEXEC flag, just like it would do if one was using different fd
values. This would enable us to pass a windows HANDLE as itself through
the ProcessLaunchInfo API.
This PR implements the unix portion of this idea. Macos and non-macos
launchers are updated to clear FD_CLOEXEC flag when duplicating a file
descriptor onto itself, and I've created a test which enables passing a
FD_CLOEXEC file descritor to the subprocess. For the windows portion,
please see the follow-up PR.
---
lldb/source/Host/macosx/objcxx/Host.mm| 11 -
.../Host/posix/ProcessLauncherPosixFork.cpp | 11 -
lldb/unittests/Host/HostTest.cpp | 40 +++
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
else if (info->GetActionArgument() == -1)
error = Status::FromErrorString(
"invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
error =
Status(::posix_spawn_file_actions_adddup2(file_actions,
info->GetFD(),
info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
"error: {0}, posix_spawn_file_actions_adddup2 "
"(action={1}, fd={2}, dup_fd={3})",
error, file_actions, info->GetFD(),
info->GetActionArgument());
+} else {
+ error =
+ Status(::posix_spawn_file_actions_addinherit_np(file_actions,
info->GetFD()),
+ eErrorTypePOSIX);
+ if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
}
break;
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 8c6d503fc7fe2..698524349e16a 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -17,6 +17,7 @@
#include "llvm/Support/Errno.h"
#include
+#include
#include
#include
#include
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+if (dup2(action.fd, action.arg) == -1)
+ ExitWithError(error_fd, "dup2");
+ } else {
+if (fcntl(action.fd, F_SETFD,
+ fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
+ ExitWithError(error_fd, "fcntl");
+ }
break;
case FileAction::eFileActionOpen:
DupDescriptor(error_fd, action.path.c_str(), action.fd, action.arg);
diff --git a/lldb/unittests/Host/HostTest
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/137978
This is a follow-up to https://github.com/llvm/llvm-project/pull/126935, which
enables passing handles to a child
process on windows systems. Unlike on unix-like systems, the handles
need to be created with the "inheritable" flag because there's to way to
change the flag value after it has been created. This is why I don't
respect the child_process_inherit flag but rather always set the flag to
true. (My next step is to delete the flag entirely.)
This does mean that pipe may be created as inheritable even if its not
necessary, but I think this is offset by the fact that windows (unlike
unixes, which pass all ~O_CLOEXEC descriptors through execve and *all*
descriptors through fork) has a way to specify the precise set of
handles to pass to a specific child process.
If this turns out to be insufficient, instead of a constructor flag, I'd
rather go with creating a separate api to create an inheritable copy of
a handle (as typically, you only want to inherit one end of the pipe).
>From 5b2721cee30a6c8b43efacb43b35c3a3150e6414 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Sun, 20 Oct 2024 02:55:02 +0200
Subject: [PATCH 1/2] [lldb/Host] Enable inheriting "non-inheritable" FDs
Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in
the (few) cases where we need to pass an FD to a subprocess. The problem
with these is that, in a multithreaded application such as lldb, there's
essentially no way to prevent them from being leaked into processes
other than the intended one.
A safer (though still not completely safe) approach is to mark the
descriptors as FD_CLOEXEC and only clear this flag in the subprocess. We
currently have something that almost does that, which is the ability to
add a `DuplicateFileAction` to our `ProcessLaunchInfo` struct (the
duplicated file descriptor will be created with the flag cleared). The
problem with *that* is that this approach is completely incompatible
with Windows.
Windows equivalents of file descriptors are `HANDLE`s, but these do not
have user controlled values -- applications are expected to work with
whatever HANDLE values are assigned by the OS. In unix terms, there is
no equivalent to the `dup2` syscall (only `dup`).
To find a way out of this conundrum, and create a miniscule API surface
that works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto
itself. Currently, this operation does nothing (it leaves the FD_CLOEXEC
flag set), because that's how `dup2(fd, fd)` behaves, but I think it's
not completely unreasonable to say that this operation should clear the
FD_CLOEXEC flag, just like it would do if one was using different fd
values. This would enable us to pass a windows HANDLE as itself through
the ProcessLaunchInfo API.
This PR implements the unix portion of this idea. Macos and non-macos
launchers are updated to clear FD_CLOEXEC flag when duplicating a file
descriptor onto itself, and I've created a test which enables passing a
FD_CLOEXEC file descritor to the subprocess. For the windows portion,
please see the follow-up PR.
---
lldb/source/Host/macosx/objcxx/Host.mm| 11 -
.../Host/posix/ProcessLauncherPosixFork.cpp | 11 -
lldb/unittests/Host/HostTest.cpp | 40 +++
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
else if (info->GetActionArgument() == -1)
error = Status::FromErrorString(
"invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
error =
Status(::posix_spawn_file_actions_adddup2(file_actions,
info->GetFD(),
info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
"error: {0}, posix_spawn_file_actions_adddup2 "
"(action={1}, fd={2}, dup_fd={3})",
error, file_actions, info->GetFD(),
info->GetActionArgument());
+} else {
+ error =
+ Status(::posix_spawn_file_actions_addinherit_np(file_actions,
info->GetFD()),
+ eErrorTypePOSIX);
+ if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
}
break;
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/Proces
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
This is a follow-up to https://github.com/llvm/llvm-project/pull/126935, which
enables passing handles to a child
process on windows systems. Unlike on unix-like systems, the handles
need to be created with the "inheritable" flag because there's to way to
change the flag value after it has been created. This is why I don't
respect the child_process_inherit flag but rather always set the flag to
true. (My next step is to delete the flag entirely.)
This does mean that pipe may be created as inheritable even if its not
necessary, but I think this is offset by the fact that windows (unlike
unixes, which pass all ~O_CLOEXEC descriptors through execve and *all*
descriptors through fork) has a way to specify the precise set of
handles to pass to a specific child process.
If this turns out to be insufficient, instead of a constructor flag, I'd
rather go with creating a separate api to create an inheritable copy of
a handle (as typically, you only want to inherit one end of the pipe).
---
Full diff: https://github.com/llvm/llvm-project/pull/137978.diff
6 Files Affected:
- (modified) lldb/source/Host/macosx/objcxx/Host.mm (+10-1)
- (modified) lldb/source/Host/posix/ProcessLauncherPosixFork.cpp (+9-2)
- (modified) lldb/source/Host/windows/PipeWindows.cpp (+3-2)
- (modified) lldb/source/Host/windows/ProcessLauncherWindows.cpp (+60-13)
- (modified) lldb/tools/lldb-server/lldb-platform.cpp (-2)
- (modified) lldb/unittests/Host/HostTest.cpp (+38)
``diff
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
else if (info->GetActionArgument() == -1)
error = Status::FromErrorString(
"invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
error =
Status(::posix_spawn_file_actions_adddup2(file_actions,
info->GetFD(),
info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
"error: {0}, posix_spawn_file_actions_adddup2 "
"(action={1}, fd={2}, dup_fd={3})",
error, file_actions, info->GetFD(),
info->GetActionArgument());
+} else {
+ error =
+ Status(::posix_spawn_file_actions_addinherit_np(file_actions,
info->GetFD()),
+ eErrorTypePOSIX);
+ if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
}
break;
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 8c6d503fc7fe2..698524349e16a 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -17,6 +17,7 @@
#include "llvm/Support/Errno.h"
#include
+#include
#include
#include
#include
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+if (dup2(action.fd, action.arg) == -1)
+ ExitWithError(error_fd, "dup2");
+ } else {
+if (fcntl(action.fd, F_SETFD,
+ fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
+ ExitWithError(error_fd, "fcntl");
+ }
break;
case FileAction::eFileActionOpen:
DupDescriptor(error_fd, action.path.c_str(), action.fd, action.arg);
diff --git a/lldb/source/Host/windows/PipeWindows.cpp
b/lldb/source/Host/windows/PipeWindows.cpp
index e3f5b629a0590..1f7f6e03519d0 100644
--- a/lldb/source/Host/windows/PipeWindows.cpp
+++ b/lldb/source/Host/windows/PipeWindows.cpp
@@ -88,8 +88,9 @@ Status PipeWindows::CreateNew(llvm::StringRef name,
std::string pipe_path = g_pipe_name_prefix.str();
pipe_path.append(name.str());
- SECURITY_ATTRIBUTES sa{sizeof(SECURITY_ATTRIBUTES), 0,
- child_process_inherit ? TRUE : FALSE};
+ // We always create inheritable handles, but we won't pass them to a child
+ // process unless explicitly requested (cf. ProcessLauncherWindows.cpp).
+ SECURITY_ATTRIBUTES sa{sizeof(SECURITY_ATTRIBUTES), 0, TRUE};
// Always open for overlapped i/o. We implement blocking manually in Read
// and Write.
diff --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
b/lldb/source/Host/windows
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
labath wrote: (Note this PR consists of two commits and the first commit is equivalent to https://github.com/llvm/llvm-project/pull/126935. For this PR, I recommend only viewing the second commit.) https://github.com/llvm/llvm-project/pull/137978 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Fix `ValueObject::AddressOf()` return value (PR #137688)
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/137688
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
}
.container { margin: 50px auto; max-width: 600px; text-align: center;
padding: 0 24px; }
a { color: #0366d6; text-decoration: none; }
a:hover { text-decoration: underline; }
h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px;
text-shadow: 0 1px 0 #fff; }
p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }
ul { list-style: none; margin: 25px 0; padding: 0; }
li { display: table-cell; font-weight: bold; width: 1%; }
.logo { display: inline-block; margin-top: 35px; }
.logo-img-2x { display: none; }
@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and ( min--moz-device-pixel-ratio: 2),
only screen and ( -o-min-device-pixel-ratio: 2/1),
only screen and (min-device-pixel-ratio: 2),
only screen and (min-resolution: 192dpi),
only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
}
#suggestions {
margin-top: 35px;
color: #ccc;
}
#suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
}
Whoa there!
You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Test all libcxxabi demangler test-cases against TrackingOutputBuffer (PR #137793)
DavidSpickett wrote: > i guess header includes would be an example Headers like ADT and so on are included in installed copies of LLVM but testing files are not. So would this break testing a standalone LLDB build? Or do we expect "standalone" to mean you configure from `lldb/` but you do have the rest of the monorepo there as well. There are those per-project tar files for each release but I'm not sure what we intend people to do with them. ...but maybe you can sidestep that by saying that libcxx must be available? https://github.com/llvm/llvm-project/pull/137793 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] add settings to control how synthetic symbol names are generated (PR #137512)
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/137512
>From fd74de70151567d402eb7c0326a6234a21cb2db7 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Sun, 27 Apr 2025 13:48:45 +0200
Subject: [PATCH 1/3] [lldb] add settings to control how synthetic symbol names
are generated
---
lldb/include/lldb/Core/ModuleList.h | 15 +++
lldb/include/lldb/lldb-enumerations.h | 6 ++
lldb/source/Core/CoreProperties.td| 5 +
lldb/source/Core/ModuleList.cpp | 8
lldb/source/Symbol/Symbol.cpp | 13 -
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/Core/ModuleList.h
b/lldb/include/lldb/Core/ModuleList.h
index 909ee08f9ba62..baed175be5313 100644
--- a/lldb/include/lldb/Core/ModuleList.h
+++ b/lldb/include/lldb/Core/ModuleList.h
@@ -67,6 +67,20 @@ static constexpr OptionEnumValueElement
g_auto_download_enum_values[] = {
},
};
+static constexpr OptionEnumValueElement
+g_synthetic_symbols_name_style_values[] = {
+{
+lldb::eSyntheticSymbolsNameStyleIndex,
+"index",
+"Function index style",
+},
+{
+lldb::eSyntheticSymbolsNameStyleFileAddress,
+"file-address",
+"Function file address in module style",
+},
+};
+
class ModuleListProperties : public Properties {
mutable llvm::sys::RWMutex m_symlink_paths_mutex;
PathMappingList m_symlink_paths;
@@ -91,6 +105,7 @@ class ModuleListProperties : public Properties {
bool GetLoadSymbolOnDemand();
lldb::SymbolDownload GetSymbolAutoDownload() const;
+ lldb::SyntheticSymbolsNameStyle GetSyntheticSymbolsNameStyle() const;
PathMappingList GetSymlinkMappings() const;
};
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 6d10cc8bcffcb..26e83cefbe571 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1391,6 +1391,12 @@ enum StopDisassemblyType {
eStopDisassemblyTypeAlways
};
+/// Format to use for unknown symbols.
+enum SyntheticSymbolsNameStyle {
+ eSyntheticSymbolsNameStyleIndex = 0,
+ eSyntheticSymbolsNameStyleFileAddress = 1,
+};
+
} // namespace lldb
#endif // LLDB_LLDB_ENUMERATIONS_H
diff --git a/lldb/source/Core/CoreProperties.td
b/lldb/source/Core/CoreProperties.td
index a1a4e994c3b9c..7eaecb729c36d 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -46,6 +46,11 @@ let Definition = "modulelist" in {
Global,
DefaultFalse,
Desc<"Enable on demand symbol loading in LLDB. LLDB will load debug info
on demand for each module based on various conditions (e.g. matched breakpoint,
resolved stack frame addresses and matched global variables/function symbols in
symbol table) to improve performance. Please refer to docs/use/ondemand.rst for
details.">;
+ def SyntheticSymbolsNameStyle: Property<"synthetic-symbols-name-style",
"Enum">,
+Global,
+DefaultEnumValue<"eSyntheticSymbolsNameStyleIndex">,
+EnumValues<"OptionEnumValues(g_synthetic_symbols_name_style_values)">,
+Desc<"Determines the way synthetic symbol names are generated for unknown
symbols">;
}
let Definition = "debugger" in {
diff --git a/lldb/source/Core/ModuleList.cpp b/lldb/source/Core/ModuleList.cpp
index 6052cc151744d..c48c5bbfb5e92 100644
--- a/lldb/source/Core/ModuleList.cpp
+++ b/lldb/source/Core/ModuleList.cpp
@@ -115,6 +115,14 @@ SymbolDownload
ModuleListProperties::GetSymbolAutoDownload() const {
g_modulelist_properties[idx].default_uint_value));
}
+lldb::SyntheticSymbolsNameStyle
+ModuleListProperties::GetSyntheticSymbolsNameStyle() const {
+ const uint32_t idx = ePropertySyntheticSymbolsNameStyle;
+ return GetPropertyAtIndexAs(
+ idx, static_cast(
+ g_modulelist_properties[idx].default_uint_value));
+}
+
FileSpec ModuleListProperties::GetClangModulesCachePath() const {
const uint32_t idx = ePropertyClangModulesCachePath;
return GetPropertyAtIndexAs(idx, {});
diff --git a/lldb/source/Symbol/Symbol.cpp b/lldb/source/Symbol/Symbol.cpp
index 4828de4fdfa37..825ca5babe28e 100644
--- a/lldb/source/Symbol/Symbol.cpp
+++ b/lldb/source/Symbol/Symbol.cpp
@@ -639,7 +639,18 @@ void Symbol::SynthesizeNameIfNeeded() const {
// breakpoints on them.
llvm::SmallString<256> name;
llvm::raw_svector_ostream os(name);
-os << GetSyntheticSymbolPrefix() << GetID();
+os << GetSyntheticSymbolPrefix();
+switch (ModuleList::GetGlobalModuleListProperties()
+.GetSyntheticSymbolsNameStyle()) {
+case eSyntheticSymbolsNameStyleIndex:
+ os << GetID();
+ break;
+case eSyntheticSymbolsNameStyleFileAddress:
+ os << "_"
+ << llvm::format_hex_no_prefix(
+m_addr_range.GetBaseAddress().GetFileAddress(), 0);
+ break;
+}
m_mangled.SetDemangledName(ConstString(os.str()));
[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #137512)
https://github.com/eronnen edited https://github.com/llvm/llvm-project/pull/137512 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] add settings to control how synthetic symbol names are generated (PR #137512)
https://github.com/eronnen edited https://github.com/llvm/llvm-project/pull/137512 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/126935
>From 566a3fb4e5a5f229b000ec53f5b08a30a87e5abd Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Sun, 20 Oct 2024 02:55:02 +0200
Subject: [PATCH] [lldb/Host] Enable inheriting "non-inheritable" FDs
Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in
the (few) cases where we need to pass an FD to a subprocess. The problem
with these is that, in a multithreaded application such as lldb, there's
essentially no way to prevent them from being leaked into processes
other than the intended one.
A safer (though still not completely safe) approach is to mark the
descriptors as FD_CLOEXEC and only clear this flag in the subprocess. We
currently have something that almost does that, which is the ability to
add a `DuplicateFileAction` to our `ProcessLaunchInfo` struct (the
duplicated file descriptor will be created with the flag cleared). The
problem with *that* is that this approach is completely incompatible
with Windows.
Windows equivalents of file descriptors are `HANDLE`s, but these do not
have user controlled values -- applications are expected to work with
whatever HANDLE values are assigned by the OS. In unix terms, there is
no equivalent to the `dup2` syscall (only `dup`).
To find a way out of this conundrum, and create a miniscule API surface
that works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto
itself. Currently, this operation does nothing (it leaves the FD_CLOEXEC
flag set), because that's how `dup2(fd, fd)` behaves, but I think it's
not completely unreasonable to say that this operation should clear the
FD_CLOEXEC flag, just like it would do if one was using different fd
values. This would enable us to pass a windows HANDLE as itself through
the ProcessLaunchInfo API.
This PR implements the unix portion of this idea. Macos and non-macos
launchers are updated to clear FD_CLOEXEC flag when duplicating a file
descriptor onto itself, and I've created a test which enables passing a
FD_CLOEXEC file descritor to the subprocess. For the windows portion,
please see the follow-up PR.
---
lldb/source/Host/macosx/objcxx/Host.mm| 11 -
.../Host/posix/ProcessLauncherPosixFork.cpp | 11 -
lldb/unittests/Host/HostTest.cpp | 46 +--
3 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
else if (info->GetActionArgument() == -1)
error = Status::FromErrorString(
"invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
error =
Status(::posix_spawn_file_actions_adddup2(file_actions,
info->GetFD(),
info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions,
const FileAction *info,
"error: {0}, posix_spawn_file_actions_adddup2 "
"(action={1}, fd={2}, dup_fd={3})",
error, file_actions, info->GetFD(),
info->GetActionArgument());
+} else {
+ error =
+ Status(::posix_spawn_file_actions_addinherit_np(file_actions,
info->GetFD()),
+ eErrorTypePOSIX);
+ if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
}
break;
diff --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 8c6d503fc7fe2..698524349e16a 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -17,6 +17,7 @@
#include "llvm/Support/Errno.h"
#include
+#include
#include
#include
#include
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+if (dup2(action.fd, action.arg) == -1)
+ ExitWithError(error_fd, "dup2");
+ } else {
+if (fcntl(action.fd, F_SETFD,
+ fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
+ ExitWithError(error_fd, "fcntl");
+ }
break;
case FileAction::eFileActionOpen:
DupDescriptor(error_fd, action.path.c_str(), action.fd, action.arg);
diff --git a/lldb/unittests/Host/HostTest
[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #137512)
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/137512
>From fd74de70151567d402eb7c0326a6234a21cb2db7 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Sun, 27 Apr 2025 13:48:45 +0200
Subject: [PATCH 1/6] [lldb] add settings to control how synthetic symbol names
are generated
---
lldb/include/lldb/Core/ModuleList.h | 15 +++
lldb/include/lldb/lldb-enumerations.h | 6 ++
lldb/source/Core/CoreProperties.td| 5 +
lldb/source/Core/ModuleList.cpp | 8
lldb/source/Symbol/Symbol.cpp | 13 -
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/Core/ModuleList.h
b/lldb/include/lldb/Core/ModuleList.h
index 909ee08f9ba62..baed175be5313 100644
--- a/lldb/include/lldb/Core/ModuleList.h
+++ b/lldb/include/lldb/Core/ModuleList.h
@@ -67,6 +67,20 @@ static constexpr OptionEnumValueElement
g_auto_download_enum_values[] = {
},
};
+static constexpr OptionEnumValueElement
+g_synthetic_symbols_name_style_values[] = {
+{
+lldb::eSyntheticSymbolsNameStyleIndex,
+"index",
+"Function index style",
+},
+{
+lldb::eSyntheticSymbolsNameStyleFileAddress,
+"file-address",
+"Function file address in module style",
+},
+};
+
class ModuleListProperties : public Properties {
mutable llvm::sys::RWMutex m_symlink_paths_mutex;
PathMappingList m_symlink_paths;
@@ -91,6 +105,7 @@ class ModuleListProperties : public Properties {
bool GetLoadSymbolOnDemand();
lldb::SymbolDownload GetSymbolAutoDownload() const;
+ lldb::SyntheticSymbolsNameStyle GetSyntheticSymbolsNameStyle() const;
PathMappingList GetSymlinkMappings() const;
};
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 6d10cc8bcffcb..26e83cefbe571 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1391,6 +1391,12 @@ enum StopDisassemblyType {
eStopDisassemblyTypeAlways
};
+/// Format to use for unknown symbols.
+enum SyntheticSymbolsNameStyle {
+ eSyntheticSymbolsNameStyleIndex = 0,
+ eSyntheticSymbolsNameStyleFileAddress = 1,
+};
+
} // namespace lldb
#endif // LLDB_LLDB_ENUMERATIONS_H
diff --git a/lldb/source/Core/CoreProperties.td
b/lldb/source/Core/CoreProperties.td
index a1a4e994c3b9c..7eaecb729c36d 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -46,6 +46,11 @@ let Definition = "modulelist" in {
Global,
DefaultFalse,
Desc<"Enable on demand symbol loading in LLDB. LLDB will load debug info
on demand for each module based on various conditions (e.g. matched breakpoint,
resolved stack frame addresses and matched global variables/function symbols in
symbol table) to improve performance. Please refer to docs/use/ondemand.rst for
details.">;
+ def SyntheticSymbolsNameStyle: Property<"synthetic-symbols-name-style",
"Enum">,
+Global,
+DefaultEnumValue<"eSyntheticSymbolsNameStyleIndex">,
+EnumValues<"OptionEnumValues(g_synthetic_symbols_name_style_values)">,
+Desc<"Determines the way synthetic symbol names are generated for unknown
symbols">;
}
let Definition = "debugger" in {
diff --git a/lldb/source/Core/ModuleList.cpp b/lldb/source/Core/ModuleList.cpp
index 6052cc151744d..c48c5bbfb5e92 100644
--- a/lldb/source/Core/ModuleList.cpp
+++ b/lldb/source/Core/ModuleList.cpp
@@ -115,6 +115,14 @@ SymbolDownload
ModuleListProperties::GetSymbolAutoDownload() const {
g_modulelist_properties[idx].default_uint_value));
}
+lldb::SyntheticSymbolsNameStyle
+ModuleListProperties::GetSyntheticSymbolsNameStyle() const {
+ const uint32_t idx = ePropertySyntheticSymbolsNameStyle;
+ return GetPropertyAtIndexAs(
+ idx, static_cast(
+ g_modulelist_properties[idx].default_uint_value));
+}
+
FileSpec ModuleListProperties::GetClangModulesCachePath() const {
const uint32_t idx = ePropertyClangModulesCachePath;
return GetPropertyAtIndexAs(idx, {});
diff --git a/lldb/source/Symbol/Symbol.cpp b/lldb/source/Symbol/Symbol.cpp
index 4828de4fdfa37..825ca5babe28e 100644
--- a/lldb/source/Symbol/Symbol.cpp
+++ b/lldb/source/Symbol/Symbol.cpp
@@ -639,7 +639,18 @@ void Symbol::SynthesizeNameIfNeeded() const {
// breakpoints on them.
llvm::SmallString<256> name;
llvm::raw_svector_ostream os(name);
-os << GetSyntheticSymbolPrefix() << GetID();
+os << GetSyntheticSymbolPrefix();
+switch (ModuleList::GetGlobalModuleListProperties()
+.GetSyntheticSymbolsNameStyle()) {
+case eSyntheticSymbolsNameStyleIndex:
+ os << GetID();
+ break;
+case eSyntheticSymbolsNameStyleFileAddress:
+ os << "_"
+ << llvm::format_hex_no_prefix(
+m_addr_range.GetBaseAddress().GetFileAddress(), 0);
+ break;
+}
m_mangled.SetDemangledName(ConstString(os.str()));
[Lldb-commits] [lldb] [lldb][test] Test all libcxxabi demangler test-cases against TrackingOutputBuffer (PR #137793)
Michael137 wrote: > For the way you're using these files (as a gtest unit test), I think it'd be > best if the tests were in `llvm/include/llvm/Testing/Demangle`. Let me try proposing moving the test and see what they say. Making changes to the demangler you have to run two sets of test-suites already anyway (`check-cxxabi` and `check-llvm-demangle`, and there's other demangling tests sprinkled around llvm). Just having to run one target would be nice. > Just a note, that if you do decide to copy the tests, it may be better to > just copy the inputs (mangled names) and then compare the "normal" demangled > names with the ones you reconstructed. This avoids needing to update two > places in case e.g. the demangler produces extra spaces somewhere. Good point, will do! https://github.com/llvm/llvm-project/pull/137793 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] add settings to control how synthetic symbol names are generated (PR #137512)
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/137512
>From fd74de70151567d402eb7c0326a6234a21cb2db7 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Sun, 27 Apr 2025 13:48:45 +0200
Subject: [PATCH 1/2] [lldb] add settings to control how synthetic symbol names
are generated
---
lldb/include/lldb/Core/ModuleList.h | 15 +++
lldb/include/lldb/lldb-enumerations.h | 6 ++
lldb/source/Core/CoreProperties.td| 5 +
lldb/source/Core/ModuleList.cpp | 8
lldb/source/Symbol/Symbol.cpp | 13 -
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/Core/ModuleList.h
b/lldb/include/lldb/Core/ModuleList.h
index 909ee08f9ba62..baed175be5313 100644
--- a/lldb/include/lldb/Core/ModuleList.h
+++ b/lldb/include/lldb/Core/ModuleList.h
@@ -67,6 +67,20 @@ static constexpr OptionEnumValueElement
g_auto_download_enum_values[] = {
},
};
+static constexpr OptionEnumValueElement
+g_synthetic_symbols_name_style_values[] = {
+{
+lldb::eSyntheticSymbolsNameStyleIndex,
+"index",
+"Function index style",
+},
+{
+lldb::eSyntheticSymbolsNameStyleFileAddress,
+"file-address",
+"Function file address in module style",
+},
+};
+
class ModuleListProperties : public Properties {
mutable llvm::sys::RWMutex m_symlink_paths_mutex;
PathMappingList m_symlink_paths;
@@ -91,6 +105,7 @@ class ModuleListProperties : public Properties {
bool GetLoadSymbolOnDemand();
lldb::SymbolDownload GetSymbolAutoDownload() const;
+ lldb::SyntheticSymbolsNameStyle GetSyntheticSymbolsNameStyle() const;
PathMappingList GetSymlinkMappings() const;
};
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 6d10cc8bcffcb..26e83cefbe571 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1391,6 +1391,12 @@ enum StopDisassemblyType {
eStopDisassemblyTypeAlways
};
+/// Format to use for unknown symbols.
+enum SyntheticSymbolsNameStyle {
+ eSyntheticSymbolsNameStyleIndex = 0,
+ eSyntheticSymbolsNameStyleFileAddress = 1,
+};
+
} // namespace lldb
#endif // LLDB_LLDB_ENUMERATIONS_H
diff --git a/lldb/source/Core/CoreProperties.td
b/lldb/source/Core/CoreProperties.td
index a1a4e994c3b9c..7eaecb729c36d 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -46,6 +46,11 @@ let Definition = "modulelist" in {
Global,
DefaultFalse,
Desc<"Enable on demand symbol loading in LLDB. LLDB will load debug info
on demand for each module based on various conditions (e.g. matched breakpoint,
resolved stack frame addresses and matched global variables/function symbols in
symbol table) to improve performance. Please refer to docs/use/ondemand.rst for
details.">;
+ def SyntheticSymbolsNameStyle: Property<"synthetic-symbols-name-style",
"Enum">,
+Global,
+DefaultEnumValue<"eSyntheticSymbolsNameStyleIndex">,
+EnumValues<"OptionEnumValues(g_synthetic_symbols_name_style_values)">,
+Desc<"Determines the way synthetic symbol names are generated for unknown
symbols">;
}
let Definition = "debugger" in {
diff --git a/lldb/source/Core/ModuleList.cpp b/lldb/source/Core/ModuleList.cpp
index 6052cc151744d..c48c5bbfb5e92 100644
--- a/lldb/source/Core/ModuleList.cpp
+++ b/lldb/source/Core/ModuleList.cpp
@@ -115,6 +115,14 @@ SymbolDownload
ModuleListProperties::GetSymbolAutoDownload() const {
g_modulelist_properties[idx].default_uint_value));
}
+lldb::SyntheticSymbolsNameStyle
+ModuleListProperties::GetSyntheticSymbolsNameStyle() const {
+ const uint32_t idx = ePropertySyntheticSymbolsNameStyle;
+ return GetPropertyAtIndexAs(
+ idx, static_cast(
+ g_modulelist_properties[idx].default_uint_value));
+}
+
FileSpec ModuleListProperties::GetClangModulesCachePath() const {
const uint32_t idx = ePropertyClangModulesCachePath;
return GetPropertyAtIndexAs(idx, {});
diff --git a/lldb/source/Symbol/Symbol.cpp b/lldb/source/Symbol/Symbol.cpp
index 4828de4fdfa37..825ca5babe28e 100644
--- a/lldb/source/Symbol/Symbol.cpp
+++ b/lldb/source/Symbol/Symbol.cpp
@@ -639,7 +639,18 @@ void Symbol::SynthesizeNameIfNeeded() const {
// breakpoints on them.
llvm::SmallString<256> name;
llvm::raw_svector_ostream os(name);
-os << GetSyntheticSymbolPrefix() << GetID();
+os << GetSyntheticSymbolPrefix();
+switch (ModuleList::GetGlobalModuleListProperties()
+.GetSyntheticSymbolsNameStyle()) {
+case eSyntheticSymbolsNameStyleIndex:
+ os << GetID();
+ break;
+case eSyntheticSymbolsNameStyleFileAddress:
+ os << "_"
+ << llvm::format_hex_no_prefix(
+m_addr_range.GetBaseAddress().GetFileAddress(), 0);
+ break;
+}
m_mangled.SetDemangledName(ConstString(os.str()));
[Lldb-commits] [lldb] Free buffer to fix memory leak on test (PR #137979)
https://github.com/itf created https://github.com/llvm/llvm-project/pull/137979
None
>From 2949d9ab36b214137d9a60dc2a6eb88f9ba4a737 Mon Sep 17 00:00:00 2001
From: Ivan Tadeu Ferreira Antunes Filho
Date: Wed, 30 Apr 2025 11:26:16 -0400
Subject: [PATCH] Free bugger and fix memory leak on test
---
lldb/unittests/Core/MangledTest.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/lldb/unittests/Core/MangledTest.cpp
b/lldb/unittests/Core/MangledTest.cpp
index aaca4270d708a..44651eb94c23b 100644
--- a/lldb/unittests/Core/MangledTest.cpp
+++ b/lldb/unittests/Core/MangledTest.cpp
@@ -605,6 +605,7 @@ TEST_P(DemanglingPartsTestFixture, DemanglingParts) {
EXPECT_EQ(get_part(OB.NameInfo.BasenameRange), basename);
EXPECT_EQ(get_part(OB.NameInfo.ScopeRange), scope);
EXPECT_EQ(get_part(OB.NameInfo.QualifiersRange), qualifiers);
+ std::free(OB.getBuffer());
}
INSTANTIATE_TEST_SUITE_P(DemanglingPartsTests, DemanglingPartsTestFixture,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/137974
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
}
.container { margin: 50px auto; max-width: 600px; text-align: center;
padding: 0 24px; }
a { color: #0366d6; text-decoration: none; }
a:hover { text-decoration: underline; }
h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px;
text-shadow: 0 1px 0 #fff; }
p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }
ul { list-style: none; margin: 25px 0; padding: 0; }
li { display: table-cell; font-weight: bold; width: 1%; }
.logo { display: inline-block; margin-top: 35px; }
.logo-img-2x { display: none; }
@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and ( min--moz-device-pixel-ratio: 2),
only screen and ( -o-min-device-pixel-ratio: 2/1),
only screen and (min-device-pixel-ratio: 2),
only screen and (min-resolution: 192dpi),
only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
}
#suggestions {
margin-top: 35px;
color: #ccc;
}
#suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
}
Whoa there!
You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Free buffer to fix memory leak on test (PR #137979)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Ivan Tadeu Ferreira Antunes Filho (itf)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/137979.diff
1 Files Affected:
- (modified) lldb/unittests/Core/MangledTest.cpp (+1)
``diff
diff --git a/lldb/unittests/Core/MangledTest.cpp
b/lldb/unittests/Core/MangledTest.cpp
index aaca4270d708a..44651eb94c23b 100644
--- a/lldb/unittests/Core/MangledTest.cpp
+++ b/lldb/unittests/Core/MangledTest.cpp
@@ -605,6 +605,7 @@ TEST_P(DemanglingPartsTestFixture, DemanglingParts) {
EXPECT_EQ(get_part(OB.NameInfo.BasenameRange), basename);
EXPECT_EQ(get_part(OB.NameInfo.ScopeRange), scope);
EXPECT_EQ(get_part(OB.NameInfo.QualifiersRange), qualifiers);
+ std::free(OB.getBuffer());
}
INSTANTIATE_TEST_SUITE_P(DemanglingPartsTests, DemanglingPartsTestFixture,
``
https://github.com/llvm/llvm-project/pull/137979
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
https://github.com/Michael137 approved this pull request. Makes sense! On the topic of ClangASTMetadata. Another thing I noticed a while ago that we might want to fix is that when we import decls from an origin, we don't copy over the metadata into the target typesystem. I forget why exactly that was causing issues, but at the very least it was causing us to recompute some properties https://github.com/llvm/llvm-project/pull/137974 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/137974 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/137974 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Free buffer to fix memory leak on test (PR #137979)
https://github.com/jyknight edited https://github.com/llvm/llvm-project/pull/137979 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix dynamic type resolution for types parsed from declarations (PR #137974)
@@ -11,6 +11,22 @@
using namespace lldb_private;
+std::optional ClangASTMetadata::GetIsDynamicCXXType() const {
+ switch (m_is_dynamic_cxx) {
+ case 0:
Michael137 wrote:
Should we make these enum cases for readability? Don't feel strongly either way.
https://github.com/llvm/llvm-project/pull/137974
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Free buffer to fix memory leak on test (PR #137979)
https://github.com/jyknight approved this pull request. Looks obvious enough, thanks! https://github.com/llvm/llvm-project/pull/137979 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Migrate attach to typed RequestHandler. (PR #137911)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/137911
>From a43b90dba56bd411b09257d47e3a3091faa09efd Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 29 Apr 2025 17:36:46 -0700
Subject: [PATCH 1/2] [lldb-dap] Migrate attach to typed RequestHandler.
This updates the `attach` request to the typed
`RequestHandler`.
Added a few more overlapping configurations to
`lldb_dap::protocol::Configuration` that are shared between launching and
attaching.
There may be some additional code we could clean-up that is no longer
referenced now that this has migrated to use well defined types.
---
lldb/tools/lldb-dap/DAP.cpp | 26 +--
.../lldb-dap/Handler/AttachRequestHandler.cpp | 214 ++
.../Handler/InitializeRequestHandler.cpp | 2 +-
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 6 +-
.../tools/lldb-dap/Handler/RequestHandler.cpp | 64 +-
lldb/tools/lldb-dap/Handler/RequestHandler.h | 21 +-
.../Handler/RestartRequestHandler.cpp | 1 -
.../lldb-dap/Protocol/ProtocolRequests.cpp| 35 ++-
.../lldb-dap/Protocol/ProtocolRequests.h | 87 +--
lldb/tools/lldb-dap/package.json | 13 +-
10 files changed, 204 insertions(+), 265 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index b593353110787..abed9983118f9 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -675,12 +675,11 @@ lldb::SBTarget DAP::CreateTarget(lldb::SBError &error) {
// enough information to determine correct arch and platform (or ELF can be
// omitted at all), so it is good to leave the user an opportunity to specify
// those. Any of those three can be left empty.
- auto target = this->debugger.CreateTarget(
- configuration.program.value_or("").data(),
- configuration.targetTriple.value_or("").data(),
- configuration.platformName.value_or("").data(),
- true, // Add dependent modules.
- error);
+ auto target = this->debugger.CreateTarget(configuration.program.data(),
+configuration.targetTriple.data(),
+configuration.platformName.data(),
+true, // Add dependent modules.
+error);
return target;
}
@@ -1192,7 +1191,7 @@ bool SendEventRequestHandler::DoExecute(lldb::SBDebugger
debugger,
}
void DAP::ConfigureSourceMaps() {
- if (configuration.sourceMap.empty() && !configuration.sourcePath)
+ if (configuration.sourceMap.empty() && configuration.sourcePath.empty())
return;
std::string sourceMapCommand;
@@ -1203,8 +1202,8 @@ void DAP::ConfigureSourceMaps() {
for (const auto &kv : configuration.sourceMap) {
strm << "\"" << kv.first << "\" \"" << kv.second << "\" ";
}
- } else if (configuration.sourcePath) {
-strm << "\".\" \"" << *configuration.sourcePath << "\"";
+ } else if (!configuration.sourcePath.empty()) {
+strm << "\".\" \"" << configuration.sourcePath << "\"";
}
RunLLDBCommands("Setting source map:", {sourceMapCommand});
@@ -1213,12 +1212,13 @@ void DAP::ConfigureSourceMaps() {
void DAP::SetConfiguration(const protocol::Configuration &config,
bool is_attach) {
configuration = config;
+ stop_at_entry = config.stopOnEntry;
this->is_attach = is_attach;
- if (configuration.customFrameFormat)
-SetFrameFormat(*configuration.customFrameFormat);
- if (configuration.customThreadFormat)
-SetThreadFormat(*configuration.customThreadFormat);
+ if (!configuration.customFrameFormat.empty())
+SetFrameFormat(configuration.customFrameFormat);
+ if (!configuration.customThreadFormat.empty())
+SetThreadFormat(configuration.customThreadFormat);
}
void DAP::SetFrameFormat(llvm::StringRef format) {
diff --git a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
index 3ef87cbef873c..fd19a4f835686 100644
--- a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
@@ -9,203 +9,135 @@
#include "DAP.h"
#include "EventHelper.h"
#include "JSONUtils.h"
+#include "LLDBUtils.h"
+#include "Protocol/ProtocolRequests.h"
#include "RequestHandler.h"
#include "lldb/API/SBListener.h"
+#include "lldb/lldb-defines.h"
+#include "llvm/Support/Error.h"
#include "llvm/Support/FileSystem.h"
+using namespace llvm;
+using namespace lldb_dap::protocol;
+
namespace lldb_dap {
-// "AttachRequest": {
-// "allOf": [ { "$ref": "#/definitions/Request" }, {
-// "type": "object",
-// "description": "Attach request; value of command field is 'attach'.",
-// "properties": {
-// "command": {
-// "type": "string",
-// "enum": [ "attach" ]
-// },
-// "arguments": {
-// "$ref": "#/definitions/AttachRequestArguments"
-//
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
@@ -8,16 +8,36 @@
#include "lldb/Core/FormatEntity.h"
#include "lldb/Utility/Status.h"
-
+#include "lldb/Utility/StreamString.h"
#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Error.h"
#include "gtest/gtest.h"
using namespace lldb_private;
+using namespace llvm;
using Definition = FormatEntity::Entry::Definition;
using Entry = FormatEntity::Entry;
-TEST(FormatEntityTest, DefinitionConstructionNameAndType) {
+namespace {
+class FormatEntityTest : public ::testing::Test {
+public:
+ Expected Format(StringRef format_str) {
JDevlieghere wrote:
Sounds good. Originally I had an `ASSERT` in there but I went with the expected
approach so the failure is attributed to the correct line.
https://github.com/llvm/llvm-project/pull/137751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Add clang resource dir to LLDB shell tests config (PR #136761)
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/136761
>From b8fec72b926a1cc02f9f3f4d3666c17aa42dd5d6 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Tue, 22 Apr 2025 13:28:04 -0700
Subject: [PATCH] [lldb][cmake] Add clang resource dir to LLDB shell tests
config
We want to be able to access the Clang resources directory in LLDB shell
tests, this commit adds the ability to do this by adding the
`CLANG_RESOURCE_DIR` CMake variable to the config for LLDB lit tests
---
lldb/cmake/modules/LLDBConfig.cmake | 11 +++
lldb/test/Shell/lit.site.cfg.py.in | 1 +
2 files changed, 12 insertions(+)
diff --git a/lldb/cmake/modules/LLDBConfig.cmake
b/lldb/cmake/modules/LLDBConfig.cmake
index 9df71edd8b359..cfd626c9358a1 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -181,6 +181,17 @@ else ()
endif ()
include_directories("${CMAKE_CURRENT_BINARY_DIR}/../clang/include")
+if(LLDB_BUILT_STANDALONE)
+ if (TARGET clang-resource-headers)
+get_target_property(CLANG_RESOURCE_DIR clang-resource-headers
INTERFACE_INCLUDE_DIRECTORIES)
+set(CLANG_RESOURCE_DIR "${CLANG_RESOURCE_DIR}/..")
+ else()
+set(CLANG_RESOURCE_DIR "${LLDB_EXTERNAL_CLANG_RESOURCE_DIR}")
+ endif()
+else()
+ get_clang_resource_dir(CLANG_RESOURCE_DIR PREFIX "${CMAKE_BINARY_DIR}")
+endif()
+
# GCC silently accepts any -Wno- option, but warns about those options
# being unrecognized only if the compilation triggers other warnings to be
# printed. Therefore, check for whether the compiler supports options in the
diff --git a/lldb/test/Shell/lit.site.cfg.py.in
b/lldb/test/Shell/lit.site.cfg.py.in
index 31a6d68618b77..7e03938b12b23 100644
--- a/lldb/test/Shell/lit.site.cfg.py.in
+++ b/lldb/test/Shell/lit.site.cfg.py.in
@@ -35,6 +35,7 @@ config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
# The shell tests use their own module caches.
config.lldb_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_LLDB@",
"lldb-shell")
config.clang_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_CLANG@",
"lldb-shell")
+config.clang_resource_dir = os.path.join("@CLANG_RESOURCE_DIR@")
import lit.llvm
lit.llvm.initialize(lit_config, config)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
@@ -274,10 +274,8 @@ static Status spawn_process(const char *progname, const
FileSpec &prog,
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
-#ifndef _WIN32
launch_info.AppendDuplicateFileAction((int)shared_socket.GetSendableFD(),
(int)shared_socket.GetSendableFD());
slydiman wrote:
https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication
> It is safe to truncate the handle (when passing it from 64-bit to 32-bit) or
> sign-extend the handle (when passing it from 32-bit to 64-bit)
https://github.com/llvm/llvm-project/pull/137978
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
https://github.com/eronnen deleted https://github.com/llvm/llvm-project/pull/137904 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
@@ -44,6 +44,34 @@ def step_out_with_scripted_plan(self, name):
stop_desc = thread.GetStopDescription(1000)
self.assertIn("Stepping out from", stop_desc, "Got right description")
+def test_step_single_instruction(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan("Steps.StepSingleInstruction")
+self.assertSuccess(err)
+
+# Verify that stepping a single instruction after "foo();" steps into
`foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("foo", frame.GetFunctionName())
eronnen wrote:
I think that testing a branch is more powerful though, because in a case of a
non branch instruction both `stepi` and `nexti` would step into the same
instruction
https://github.com/llvm/llvm-project/pull/137904
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Upstream lldb-rpc-gen and LLDB RPC server-side emitters (PR #136748)
chelcassanova wrote: Looking at this patch again, I think this can actually be split into 4 patches: - One that just has the Python scripts - One that has the shell tests - One with the emitters (`RPCServerSourceEmitter` and `RPCServerHeaderEmitter`) - One with the `lldb-rpc-gen` tool and the RPC common code for `lldb-rpc-gen` That should make this easier to review. @DavidSpickett I can still draft up a design doc, but for the sake of readability I'm also going to split this patch up as well. https://github.com/llvm/llvm-project/pull/136748 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix raciness in launch and attach tests (PR #137920)
JDevlieghere wrote: > Someone once told me: "Whatever problem you're trying to solve, if you're > using atomics, now you've got two problems." > > I can't say I've always followed that advice, but I do think that atomics are > rarely the right solution to a problem. And I think this is a good example of > that. > > What you want is not to suppress _a_ event (whatever it might be). You want > to suppress a very specific event (that is supposed to be generated by the > action you're about to perform). That means that something needs to ensure > that the other thread reads this flag after you've generated the event. If > that's true, then you already have a happens-before relationship and the > atomic is not necessary. If it isn't (there is no happens-before), then the > atomic will not help. You're right. I have an implementation that used a mutex but it made the same mistake I have here with the atomic. Luckily that's easily solvable by putting the code that generates the stop and consumes the stop in the critical section. > That said, why is ConnectRemote generating a stopped event in synchronous > mode? Maybe that's the bug we should fix? That's a long standing bug that comes up about once or twice a year. I spend some time looking into that at some point, but it's so long ago that I don't remember what the blocker was. That said, solving that isn't sufficient for the problem at hand, since we need to solve the asynchronous case as well. https://github.com/llvm/llvm-project/pull/137920 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b85f37a - [lldb][test] Free buffer to fix memory leak on test (#137979)
Author: Ivan Tadeu Ferreira Antunes Filho
Date: 2025-04-30T16:02:33-04:00
New Revision: b85f37a132827c8c298c2362ef0429f0dd71adb2
URL:
https://github.com/llvm/llvm-project/commit/b85f37a132827c8c298c2362ef0429f0dd71adb2
DIFF:
https://github.com/llvm/llvm-project/commit/b85f37a132827c8c298c2362ef0429f0dd71adb2.diff
LOG: [lldb][test] Free buffer to fix memory leak on test (#137979)
Added:
Modified:
lldb/unittests/Core/MangledTest.cpp
Removed:
diff --git a/lldb/unittests/Core/MangledTest.cpp
b/lldb/unittests/Core/MangledTest.cpp
index aaca4270d708a..44651eb94c23b 100644
--- a/lldb/unittests/Core/MangledTest.cpp
+++ b/lldb/unittests/Core/MangledTest.cpp
@@ -605,6 +605,7 @@ TEST_P(DemanglingPartsTestFixture, DemanglingParts) {
EXPECT_EQ(get_part(OB.NameInfo.BasenameRange), basename);
EXPECT_EQ(get_part(OB.NameInfo.ScopeRange), scope);
EXPECT_EQ(get_part(OB.NameInfo.QualifiersRange), qualifiers);
+ std::free(OB.getBuffer());
}
INSTANTIATE_TEST_SUITE_P(DemanglingPartsTests, DemanglingPartsTestFixture,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Free buffer to fix memory leak on test (PR #137979)
https://github.com/itf closed https://github.com/llvm/llvm-project/pull/137979 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Add an RAII helper for synchronous mode (NFC) (PR #137900)
@@ -235,4 +235,15 @@ std::string GetStringValue(const lldb::SBStructuredData
&data) {
return str;
}
+ScopeSyncMode::ScopeSyncMode(lldb::SBDebugger &debugger)
+: m_debugger(debugger) {
+ assert(m_debugger.GetAsync() && "Debugger not in asynchronous mode!");
jimingham wrote:
And sync vrs. async is purely a matter of what we do with process events, so it
could reasonably be a process property.
https://github.com/llvm/llvm-project/pull/137900
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
@@ -44,6 +44,34 @@ def step_out_with_scripted_plan(self, name):
stop_desc = thread.GetStopDescription(1000)
self.assertIn("Stepping out from", stop_desc, "Got right description")
+def test_step_single_instruction(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan("Steps.StepSingleInstruction")
+self.assertSuccess(err)
+
+# Verify that stepping a single instruction after "foo();" steps into
`foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("foo", frame.GetFunctionName())
+
+def test_step_single_instruction_with_step_over(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan(
+"Steps.StepSingleInstructionWithStepOver"
+)
+self.assertSuccess(err)
+
+# Verify that stepping over an instruction doesn't step into `foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("main", frame.GetFunctionName())
jimingham wrote:
If the thread plan failed to move at all, this assert would pass. Figuring out
where you go with nexti is a little trickier than stepi, so it's probably okay
here to just assert that you didn't step into foo but the PC did change.
https://github.com/llvm/llvm-project/pull/137904
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
@@ -44,6 +44,34 @@ def step_out_with_scripted_plan(self, name):
stop_desc = thread.GetStopDescription(1000)
self.assertIn("Stepping out from", stop_desc, "Got right description")
+def test_step_single_instruction(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan("Steps.StepSingleInstruction")
+self.assertSuccess(err)
+
+# Verify that stepping a single instruction after "foo();" steps into
`foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("foo", frame.GetFunctionName())
jimingham wrote:
In the case of step-i, we are really trying to assert that we step just one
instruction. That's actually not all that hard to test exactly. Just add some
simple arithmetic computation to the test, so it won't have branches, and then
stop at the beginning of the computation, run your step-i plan, and assert that
you did get to the NEXT instruction on the instruction list.
https://github.com/llvm/llvm-project/pull/137904
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
https://github.com/jimingham edited https://github.com/llvm/llvm-project/pull/137904 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
@@ -274,10 +274,8 @@ static Status spawn_process(const char *progname, const
FileSpec &prog,
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
-#ifndef _WIN32
launch_info.AppendDuplicateFileAction((int)shared_socket.GetSendableFD(),
(int)shared_socket.GetSendableFD());
slydiman wrote:
Here is the problem.
AppendDuplicateFileAction() means fd is int.
But GetSendableFD() returns shared_fd_t = lldb::pipe_t = void * = HANDLE. We
cannot just cast HANDLE to int.
https://github.com/llvm/llvm-project/pull/137978
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
https://github.com/slydiman edited https://github.com/llvm/llvm-project/pull/137978 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Add clang resource dir to LLDB shell tests config (PR #136761)
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-arm-ubuntu` running
on `linaro-lldb-arm-ubuntu` while building `lldb` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/18/builds/15300
Here is the relevant piece of the build log for the reference
```
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: test_utils/TestPExpectTest.py (1152 of 3009)
PASS: lldb-api :: test_utils/base/TestBaseTest.py (1153 of 3009)
UNSUPPORTED: lldb-api :: tools/lldb-dap/attach/TestDAP_attach.py (1154 of 3009)
UNSUPPORTED: lldb-api :: tools/lldb-dap/attach/TestDAP_attachByPortNum.py (1155
of 3009)
UNSUPPORTED: lldb-api ::
tools/lldb-dap/breakpoint-events/TestDAP_breakpointEvents.py (1156 of 3009)
PASS: lldb-api :: python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
(1157 of 3009)
PASS: lldb-api :: tools/lldb-dap/breakpoint/TestDAP_breakpointLocations.py
(1158 of 3009)
PASS: lldb-api :: tools/lldb-dap/breakpoint/TestDAP_logpoints.py (1159 of 3009)
PASS: lldb-api :: tools/lldb-dap/breakpoint/TestDAP_setExceptionBreakpoints.py
(1160 of 3009)
UNRESOLVED: lldb-api :: tools/lldb-dap/breakpoint/TestDAP_setBreakpoints.py
(1161 of 3009)
TEST 'lldb-api ::
tools/lldb-dap/breakpoint/TestDAP_setBreakpoints.py' FAILED
Script:
--
/usr/bin/python3.10
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/dotest.py
-u CXXFLAGS -u CFLAGS --env
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./lib --env
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/include --env
LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin --arch
armv8l --build-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex
--lldb-module-cache-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/lldb
--compiler /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/clang
--dsymutil /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/dsymutil
--make /usr/bin/gmake --llvm-tools-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin --lldb-obj-root
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/tools/lldb --lldb-libs-dir
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./lib
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/breakpoint
-p TestDAP_setBreakpoints.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision
ff8fc5bc45c166d686e485b306fdcdadd5b02637)
clang revision ff8fc5bc45c166d686e485b306fdcdadd5b02637
llvm revision ff8fc5bc45c166d686e485b306fdcdadd5b02637
Skipping the following test categories: ['libc++', 'dsym', 'gmodules',
'debugserver', 'objc']
--
Command Output (stderr):
--
FAIL: LLDB (/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang-arm) ::
test_clear_breakpoints_unset_breakpoints
(TestDAP_setBreakpoints.TestDAP_setBreakpoints)
= DEBUG ADAPTER PROTOCOL LOGS =
1746035536.445734978 --> (stdin/stdout)
{"command":"initialize","type":"request","arguments":{"adapterID":"lldb-native","clientID":"vscode","columnsStartAt1":true,"linesStartAt1":true,"locale":"en-us","pathFormat":"path","supportsRunInTerminalRequest":true,"supportsVariablePaging":true,"supportsVariableType":true,"supportsStartDebuggingRequest":true,"supportsProgressReporting":true,"$__lldb_sourceInitFile":false},"seq":1}
1746035536.449244261 <-- (stdin/stdout) {"body":{"$__lldb_version":"lldb
version 21.0.0git (https://github.com/llvm/llvm-project.git revision
ff8fc5bc45c166d686e485b306fdcdadd5b02637)\n clang revision
ff8fc5bc45c166d686e485b306fdcdadd5b02637\n llvm revision
ff8fc5bc45c166d686e485b306fdcdadd5b02637","completionTriggerCharacters":[".","
","\t"],"exceptionBreakpointFilters":[{"default":false,"filter":"cpp_catch","label":"C++
Catch"},{"default":false,"filter":"cpp_throw","label":"C++
Throw"},{"default":false,"filter":"objc_catch","label":"Objective-C
Catch"},{"default":false,"filter":"objc_throw","label":"Objective-C
Throw"}],"supportTerminateDebuggee":true,"supportsBreakpointLocationsRequest":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsDisassembleRequest":true,"supportsEvaluateForHovers":true,"supportsExceptionInfoRequest":true,"supportsExceptionOptions":true,"supportsFunctionBreakpoints":true,"supportsHitConditionalBreakpoints":true,"supportsInstructionBreakpoints":true,"supportsLogPoints":true,"supportsModulesRequest":true,"supportsReadMemoryRequest":true,"supportsRestartRequest":t
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
@@ -274,10 +274,8 @@ static Status spawn_process(const char *progname, const
FileSpec &prog,
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
-#ifndef _WIN32
launch_info.AppendDuplicateFileAction((int)shared_socket.GetSendableFD(),
(int)shared_socket.GetSendableFD());
slydiman wrote:
I like the overall approach. But we must work with FileAction more clearly.
ProcessLauncherWindows::GetStdioHandle() uses
launch_info.GetFileActionForFD(STDOUT_FILENO) and such. It means that
FileAction.m_fd is std fd. But here you stores HANDLE converted to int. We
cannot store HANDLE and std fd in the same property, even if the value is < 1K
and can be converted to int. We must use shared_fd_t in FileAction or a union
with relevant types for different actions.
https://github.com/llvm/llvm-project/pull/137978
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][TypeSystemClang] Allow arrays to be dereferenced in C/C++. (PR #135843)
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/135843
>From 7cca4bf228ab2b882a1a6487eb24948cba9e5b12 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 16 Apr 2025 00:30:51 +0500
Subject: [PATCH 1/4] [lldb][TypeSystemClang] Add a function
`IsValidDereferenceType` to TypeSystem to allow arrays to be dereferenced in
C/C++.
---
lldb/include/lldb/Symbol/CompilerType.h | 2 ++
lldb/include/lldb/Symbol/TypeSystem.h| 2 ++
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp | 9 +
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h | 2 ++
lldb/source/Symbol/CompilerType.cpp | 7 +++
lldb/source/ValueObject/ValueObject.cpp | 7 ---
6 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/lldb/include/lldb/Symbol/CompilerType.h
b/lldb/include/lldb/Symbol/CompilerType.h
index fdbc2057ac10f..3d726fca5a16c 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -186,6 +186,8 @@ class CompilerType {
bool IsReferenceType(CompilerType *pointee_type = nullptr,
bool *is_rvalue = nullptr) const;
+ bool IsValidDereferenceType() const;
+
bool ShouldTreatScalarValueAsAddress() const;
bool IsScalarType() const;
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h
b/lldb/include/lldb/Symbol/TypeSystem.h
index df87fea32b72a..753352b45e2d9 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -489,6 +489,8 @@ class TypeSystem : public PluginInterface,
virtual bool IsReferenceType(lldb::opaque_compiler_type_t type,
CompilerType *pointee_type, bool *is_rvalue) =
0;
+ virtual bool IsValidDereferenceType(lldb::opaque_compiler_type_t type) = 0;
+
virtual bool
ShouldTreatScalarValueAsAddress(lldb::opaque_compiler_type_t type) {
return IsPointerOrReferenceType(type, nullptr);
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index cb0ecd6ebd406..4165e08a63302 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -3443,6 +3443,13 @@ bool
TypeSystemClang::IsReferenceType(lldb::opaque_compiler_type_t type,
return false;
}
+bool TypeSystemClang::IsValidDereferenceType(
+lldb::opaque_compiler_type_t type) {
+ CompilerType compiler_type =
GetType(clang::QualType::getFromOpaquePtr(type));
+ return compiler_type.IsPointerOrReferenceType() ||
+ compiler_type.IsArrayType();
+}
+
bool TypeSystemClang::IsFloatingPointType(lldb::opaque_compiler_type_t type,
uint32_t &count, bool &is_complex) {
if (type) {
@@ -6544,6 +6551,8 @@ llvm::Expected
TypeSystemClang::GetChildCompilerTypeAtIndex(
return size_or_err.takeError();
child_byte_size = *size_or_err;
child_byte_offset = (int32_t)idx * (int32_t)child_byte_size;
+ if (idx == 0)
+child_is_deref_of_parent = true;
return element_type;
}
}
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index 93933846d114d..8924cf99e8f7f 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -716,6 +716,8 @@ class TypeSystemClang : public TypeSystem {
bool IsReferenceType(lldb::opaque_compiler_type_t type,
CompilerType *pointee_type, bool *is_rvalue) override;
+ bool IsValidDereferenceType(lldb::opaque_compiler_type_t type) override;
+
bool IsScalarType(lldb::opaque_compiler_type_t type) override;
bool IsTypedefType(lldb::opaque_compiler_type_t type) override;
diff --git a/lldb/source/Symbol/CompilerType.cpp
b/lldb/source/Symbol/CompilerType.cpp
index 90c4dbf0c6206..183a6aa0ba6d4 100644
--- a/lldb/source/Symbol/CompilerType.cpp
+++ b/lldb/source/Symbol/CompilerType.cpp
@@ -233,6 +233,13 @@ bool CompilerType::IsReferenceType(CompilerType
*pointee_type,
return false;
}
+bool CompilerType::IsValidDereferenceType() const {
+ if (IsValid())
+if (auto type_system_sp = GetTypeSystem())
+ return type_system_sp->IsValidDereferenceType(m_type);
+ return false;
+}
+
bool CompilerType::ShouldTreatScalarValueAsAddress() const {
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
diff --git a/lldb/source/ValueObject/ValueObject.cpp
b/lldb/source/ValueObject/ValueObject.cpp
index d5e0d462c3759..2c95e27c6e2c9 100644
--- a/lldb/source/ValueObject/ValueObject.cpp
+++ b/lldb/source/ValueObject/ValueObject.cpp
@@ -2794,8 +2794,9 @@ ValueObjectSP ValueObject::Dereference(Status &error) {
if (m_deref_valobj)
return m_deref_valobj->GetSP();
- const bool is_pointer_or_reference_type
[Lldb-commits] [lldb] [lldb-dap] Add an RAII helper for synchronous mode (NFC) (PR #137900)
@@ -235,4 +235,15 @@ std::string GetStringValue(const lldb::SBStructuredData
&data) {
return str;
}
+ScopeSyncMode::ScopeSyncMode(lldb::SBDebugger &debugger)
+: m_debugger(debugger) {
+ assert(m_debugger.GetAsync() && "Debugger not in asynchronous mode!");
jimingham wrote:
BTW, Sync vrs. Async really should be a property of the process not the
debugger. It doesn't so much matter when there's one target/process per
debugger, but if you have multiple processes, you can't guarantee that all of
them want to be in either sync or async mode at the same time.
https://github.com/llvm/llvm-project/pull/137900
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
https://github.com/jimingham edited https://github.com/llvm/llvm-project/pull/137904 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
@@ -274,10 +274,8 @@ static Status spawn_process(const char *progname, const
FileSpec &prog,
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
-#ifndef _WIN32
launch_info.AppendDuplicateFileAction((int)shared_socket.GetSendableFD(),
(int)shared_socket.GetSendableFD());
labath wrote:
It's definitely not the most elegant piece of code I've written, but it does
work. A HANDLE is not a real pointer anyway -- just an OS-assigned identifier
that they chose to stick in a void*. I'm not sure how it gets chosen, but in my
experiments all of the values were low integer values (<=1k). I've been
planning to follow this up with a change to make ProcessLaunchInfo accept
64-bit integers, which should make it safer (and avoid the warnings about casts
of pointers to ints of different size). We can definitely also do it
beforehand, but I wanted to get this out to see what you think of the overall
approach.
https://github.com/llvm/llvm-project/pull/137978
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix raciness in launch and attach tests (PR #137920)
ashgti wrote: We could block the DAP queue until we get the stop event before we send the `initialized` event maybe. https://github.com/llvm/llvm-project/blob/d7f096e3fe611ae2cc7403c3cf2f88255a47b61d/lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp#L70-L77 is where I am thinking we can wait for the stopped event. That may also fix this by preventing us from handling the next DAP request until we get the 'stopped' event, which I think would arrive after the 'module' events are done processing. https://github.com/llvm/llvm-project/pull/137920 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Add clang resource dir to LLDB shell tests config (PR #136761)
https://github.com/bulbazord approved this pull request. I'm alright with this https://github.com/llvm/llvm-project/pull/136761 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] ff8fc5b - [lldb][cmake] Add clang resource dir to LLDB shell tests config (#136761)
Author: Chelsea Cassanova
Date: 2025-04-30T10:10:05-07:00
New Revision: ff8fc5bc45c166d686e485b306fdcdadd5b02637
URL:
https://github.com/llvm/llvm-project/commit/ff8fc5bc45c166d686e485b306fdcdadd5b02637
DIFF:
https://github.com/llvm/llvm-project/commit/ff8fc5bc45c166d686e485b306fdcdadd5b02637.diff
LOG: [lldb][cmake] Add clang resource dir to LLDB shell tests config (#136761)
We want to be able to access the Clang resources directory in LLDB shell
tests, this commit adds the ability to do this by populating the
`CLANG_RESOURCE_DIR` variable in LLDBConfig.cmake.
Added:
Modified:
lldb/cmake/modules/LLDBConfig.cmake
lldb/test/Shell/lit.site.cfg.py.in
Removed:
diff --git a/lldb/cmake/modules/LLDBConfig.cmake
b/lldb/cmake/modules/LLDBConfig.cmake
index 9df71edd8b359..cfd626c9358a1 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -181,6 +181,17 @@ else ()
endif ()
include_directories("${CMAKE_CURRENT_BINARY_DIR}/../clang/include")
+if(LLDB_BUILT_STANDALONE)
+ if (TARGET clang-resource-headers)
+get_target_property(CLANG_RESOURCE_DIR clang-resource-headers
INTERFACE_INCLUDE_DIRECTORIES)
+set(CLANG_RESOURCE_DIR "${CLANG_RESOURCE_DIR}/..")
+ else()
+set(CLANG_RESOURCE_DIR "${LLDB_EXTERNAL_CLANG_RESOURCE_DIR}")
+ endif()
+else()
+ get_clang_resource_dir(CLANG_RESOURCE_DIR PREFIX "${CMAKE_BINARY_DIR}")
+endif()
+
# GCC silently accepts any -Wno- option, but warns about those options
# being unrecognized only if the compilation triggers other warnings to be
# printed. Therefore, check for whether the compiler supports options in the
diff --git a/lldb/test/Shell/lit.site.cfg.py.in
b/lldb/test/Shell/lit.site.cfg.py.in
index 31a6d68618b77..7e03938b12b23 100644
--- a/lldb/test/Shell/lit.site.cfg.py.in
+++ b/lldb/test/Shell/lit.site.cfg.py.in
@@ -35,6 +35,7 @@ config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
# The shell tests use their own module caches.
config.lldb_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_LLDB@",
"lldb-shell")
config.clang_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_CLANG@",
"lldb-shell")
+config.clang_resource_dir = os.path.join("@CLANG_RESOURCE_DIR@")
import lit.llvm
lit.llvm.initialize(lit_config, config)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Add clang resource dir to LLDB shell tests config (PR #136761)
https://github.com/chelcassanova closed https://github.com/llvm/llvm-project/pull/136761 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Add clang resource dir to LLDB shell tests config (PR #136761)
@@ -1,6 +1,12 @@ add_custom_target(lldb-shell-test-deps) set_target_properties(lldb-shell-test-deps PROPERTIES FOLDER "LLDB/Tests") add_dependencies(lldb-shell-test-deps lldb-test-depends) +if(LLDB_BUILT_STANDALONE) + get_target_property(CLANG_RESOURCE_DIR clang-resource-headers INTERFACE_INCLUDE_DIRECTORIES) chelcassanova wrote: This actually only happens if the `clang-resource-dir` target doesn't exist. When I built standalone, that target did exist so the `LLDB_EXTERNAL_CLANG_RESOURCE_DIR` is never populated. I changed it so that if that target doesn't exist when we're trying to set `CLANG_RESOURCE_DIR`, we use `LLDB_EXTERNAL_CLANG_RESOURCE_DIR`. https://github.com/llvm/llvm-project/pull/136761 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] print a notice when `source list` paging reaches the end of th… (PR #137515)
@@ -1067,7 +1067,14 @@ class CommandObjectSourceList : public
CommandObjectParsed {
&result.GetOutputStream(), m_options.num_lines,
m_options.reverse, GetBreakpointLocations())) {
result.SetStatus(eReturnStatusSuccessFinishResult);
+} else {
+ if (target.GetSourceManager().AsLastLine(m_options.reverse)) {
jimingham wrote:
If you go in reverse and try to page past the beginning of the file we really
shouldn't print "Reached the end to the file". Maybe:
result.AppendNoteWithFormat("Reached {0} of the file, no more to page",
m_options.reverse ? "beginning" : "end");
https://github.com/llvm/llvm-project/pull/137515
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] print a notice when `source list` paging reaches the end of th… (PR #137515)
@@ -0,0 +1,26 @@
+# RUN: %clang_host -g -O0 %S/Inputs/sigchld.c -o %t.out
+# RUN: %lldb %t.out -b -s %s 2>&1 | FileCheck %s
+
+list
+# CHECK: note: No source available
+
+b main
+# CHECK: Breakpoint 1:
+
+r
+# CHECK: int main()
+
+list
+# CHECK: if (child_pid == 0)
+
+list
+# CHECK: printf("signo = %d\n", SIGCHLD);
+
+list
+# CHECK: return 0;
+
+list
+# CHECK: note: Reached end of the file, no more to page
+
+list
jimingham wrote:
That's good. There should also be a test for scrolling past the beginning of
the file in reverse, since you added a good behavior for that.
https://github.com/llvm/llvm-project/pull/137515
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
@@ -44,6 +44,34 @@ def step_out_with_scripted_plan(self, name):
stop_desc = thread.GetStopDescription(1000)
self.assertIn("Stepping out from", stop_desc, "Got right description")
+def test_step_single_instruction(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan("Steps.StepSingleInstruction")
+self.assertSuccess(err)
+
+# Verify that stepping a single instruction after "foo();" steps into
`foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("foo", frame.GetFunctionName())
+
+def test_step_single_instruction_with_step_over(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan(
+"Steps.StepSingleInstructionWithStepOver"
+)
+self.assertSuccess(err)
+
+# Verify that stepping over an instruction doesn't step into `foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("main", frame.GetFunctionName())
jimingham wrote:
You might also assert before the nexti that you really are at a branch (you can
get the instruction list for the function, find the instruction you are stopped
at and ask it IsBranch. It seems really unlikely that any
compiler/architecture would do more for a call to a `void (*)(void)` would emit
more than a single branch and link, but it's better not to rely on that.
https://github.com/llvm/llvm-project/pull/137904
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
https://github.com/jimingham edited https://github.com/llvm/llvm-project/pull/137904 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Add an RAII helper for synchronous mode (NFC) (PR #137900)
@@ -235,4 +235,15 @@ std::string GetStringValue(const lldb::SBStructuredData
&data) {
return str;
}
+ScopeSyncMode::ScopeSyncMode(lldb::SBDebugger &debugger)
+: m_debugger(debugger) {
+ assert(m_debugger.GetAsync() && "Debugger not in asynchronous mode!");
jimingham wrote:
It's not just okay to allow scripts to temporarily change the Sync vrs. Async
state of the debugger, it's pretty close to necessary. Since we don't have a
way from the SB API's to hijack the Process listener, the only way you can
write a command that does "step, check something, step again" is to change the
debugger mode to Sync.
We could solve this by forcing everyone to write scripted thread plans for this
sort of thing, but that's conceptually more difficult, and I think a lot of
people aren't willing to figure that out.
https://github.com/llvm/llvm-project/pull/137900
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
@@ -153,10 +173,37 @@ constexpr llvm::StringRef lookupStrings[] = {
"${target.file.fullpath}",
"${var.dummy-var-to-test-wildcard}"};
-TEST(FormatEntity, LookupAllEntriesInTree) {
+TEST_F(FormatEntityTest, LookupAllEntriesInTree) {
for (const llvm::StringRef testString : lookupStrings) {
Entry e;
EXPECT_TRUE(FormatEntity::Parse(testString, e).Success())
<< "Formatting " << testString << " did not succeed";
}
}
+
+TEST_F(FormatEntityTest, Scope) {
+ // Scope with one alternative.
+ EXPECT_THAT_EXPECTED(Format("{${frame.pc}|foo}"), HasValue("foo"));
+
+ // Scope with multiple alternatives.
+ EXPECT_THAT_EXPECTED(Format("{${frame.pc}|${function.name}|foo}"),
+ HasValue("foo"));
+
+ // Escaped pipe inside a scope.
+ EXPECT_THAT_EXPECTED(Format("{foo\\|bar}"), HasValue("foo|bar"));
+
+ // Unescaped pipe outside a scope.
+ EXPECT_THAT_EXPECTED(Format("foo|bar"), HasValue("foo|bar"));
+
+ // Nested scopes. Note that scopes always resolve.
+ EXPECT_THAT_EXPECTED(Format("{{${frame.pc}|foo}|{bar}}"), HasValue("foo"));
+ EXPECT_THAT_EXPECTED(Format("{{${frame.pc}}|{bar}}"), HasValue(""));
+
+ // Pipe between scopes.
+ EXPECT_THAT_EXPECTED(Format("{foo}|{bar}"), HasValue("foo|bar"));
+ EXPECT_THAT_EXPECTED(Format("{foo}||{bar}"), HasValue("foo||bar"));
+
+ // Empty space between pipes.
+ EXPECT_THAT_EXPECTED(Format("{{foo}||{bar}}"), HasValue("foo"));
Michael137 wrote:
What would we print for `{ { ${frame.pc} } | { bar } }`?
https://github.com/llvm/llvm-project/pull/137751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
@@ -153,10 +173,37 @@ constexpr llvm::StringRef lookupStrings[] = {
"${target.file.fullpath}",
"${var.dummy-var-to-test-wildcard}"};
-TEST(FormatEntity, LookupAllEntriesInTree) {
+TEST_F(FormatEntityTest, LookupAllEntriesInTree) {
for (const llvm::StringRef testString : lookupStrings) {
Entry e;
EXPECT_TRUE(FormatEntity::Parse(testString, e).Success())
<< "Formatting " << testString << " did not succeed";
}
}
+
+TEST_F(FormatEntityTest, Scope) {
+ // Scope with one alternative.
+ EXPECT_THAT_EXPECTED(Format("{${frame.pc}|foo}"), HasValue("foo"));
+
+ // Scope with multiple alternatives.
+ EXPECT_THAT_EXPECTED(Format("{${frame.pc}|${function.name}|foo}"),
+ HasValue("foo"));
+
+ // Escaped pipe inside a scope.
+ EXPECT_THAT_EXPECTED(Format("{foo\\|bar}"), HasValue("foo|bar"));
+
+ // Unescaped pipe outside a scope.
+ EXPECT_THAT_EXPECTED(Format("foo|bar"), HasValue("foo|bar"));
+
+ // Nested scopes. Note that scopes always resolve.
+ EXPECT_THAT_EXPECTED(Format("{{${frame.pc}|foo}|{bar}}"), HasValue("foo"));
+ EXPECT_THAT_EXPECTED(Format("{{${frame.pc}}|{bar}}"), HasValue(""));
Michael137 wrote:
Should we maybe disallow an alternative between scopes (or rather where a scope
is on the left-hand side)? I guess technically it does "work", but one would
have to know the intricacies of this language to understand why. Would there
ever be a case where writing `{ { foo } | { bar } }` would not be a bug?
https://github.com/llvm/llvm-project/pull/137751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/137751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
https://github.com/Michael137 deleted https://github.com/llvm/llvm-project/pull/137751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/137751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Free buffer to fix memory leak on test (PR #137979)
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu`
running on `linaro-lldb-aarch64-ubuntu` while building `lldb` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/59/builds/16947
Here is the relevant piece of the build log for the reference
```
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteCompletion.py (1209 of 2154)
UNSUPPORTED: lldb-api :: tools/lldb-server/TestGdbRemoteFork.py (1210 of 2154)
UNSUPPORTED: lldb-api :: tools/lldb-server/TestGdbRemoteForkNonStop.py (1211 of
2154)
UNSUPPORTED: lldb-api :: tools/lldb-server/TestGdbRemoteForkResume.py (1212 of
2154)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteExitCode.py (1213 of 2154)
PASS: lldb-api :: terminal/TestEditline.py (1214 of 2154)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteHostInfo.py (1215 of 2154)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteModuleInfo.py (1216 of 2154)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteAuxvSupport.py (1217 of 2154)
UNRESOLVED: lldb-api :: tools/lldb-dap/variables/TestDAP_variables.py (1218 of
2154)
TEST 'lldb-api ::
tools/lldb-dap/variables/TestDAP_variables.py' FAILED
Script:
--
/usr/bin/python3.10
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/dotest.py
-u CXXFLAGS -u CFLAGS --env
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --env
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include
--env LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin
--arch aarch64 --build-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex
--lldb-module-cache-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/lldb
--compiler /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/clang
--dsymutil /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/dsymutil
--make /usr/bin/gmake --llvm-tools-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin --lldb-obj-root
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb --lldb-libs-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/variables
-p TestDAP_variables.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision
b85f37a132827c8c298c2362ef0429f0dd71adb2)
clang revision b85f37a132827c8c298c2362ef0429f0dd71adb2
llvm revision b85f37a132827c8c298c2362ef0429f0dd71adb2
Skipping the following test categories: ['libc++', 'dsym', 'gmodules',
'debugserver', 'objc']
--
Command Output (stderr):
--
UNSUPPORTED: LLDB
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) ::
test_darwin_dwarf_missing_obj (TestDAP_variables.TestDAP_variables) (requires
one of macosx, darwin, ios, tvos, watchos, bridgeos, iphonesimulator,
watchsimulator, appletvsimulator)
UNSUPPORTED: LLDB
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) ::
test_darwin_dwarf_missing_obj_with_symbol_ondemand_enabled
(TestDAP_variables.TestDAP_variables) (requires one of macosx, darwin, ios,
tvos, watchos, bridgeos, iphonesimulator, watchsimulator, appletvsimulator)
= DEBUG ADAPTER PROTOCOL LOGS =
1746043907.483640432 --> (stdin/stdout)
{"command":"initialize","type":"request","arguments":{"adapterID":"lldb-native","clientID":"vscode","columnsStartAt1":true,"linesStartAt1":true,"locale":"en-us","pathFormat":"path","supportsRunInTerminalRequest":true,"supportsVariablePaging":true,"supportsVariableType":true,"supportsStartDebuggingRequest":true,"supportsProgressReporting":true,"$__lldb_sourceInitFile":false},"seq":1}
1746043907.485764980 <-- (stdin/stdout) {"body":{"$__lldb_version":"lldb
version 21.0.0git (https://github.com/llvm/llvm-project.git revision
b85f37a132827c8c298c2362ef0429f0dd71adb2)\n clang revision
b85f37a132827c8c298c2362ef0429f0dd71adb2\n llvm revision
b85f37a132827c8c298c2362ef0429f0dd71adb2","completionTriggerCharacters":[".","
","\t"],"exceptionBreakpointFilters":[{"default":false,"filter":"cpp_catch","label":"C++
Catch"},{"default":false,"filter":"cpp_throw","label":"C++
Throw"},{"default":false,"filter":"objc_catch","label":"Objective-C
Catch"},{"default":false,"filter":"objc_throw","label":"Objective-C
Throw"}],"supportTerminateDebuggee":true,"supportsBreakpointLocationsRequest":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,
[Lldb-commits] [lldb] [lldb][cmake] Error out when building debugserver with CMake 4 (PR #138020)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Chelsea Cassanova (chelcassanova)
Changes
CMake 4 no longer sets the `CMAKE_OSX_SYSROOT` variable by default. If you've
updated to CMake 4 on macOS (e.g. with brew) and try building LLDB with
CMake/ninja, this will yield an error when building debugserver that clang is
unable to run since it tries to compile files that don't exist.
These files are supposed to be generated by the `mig` process. `mig` needs the
`CMAKE_OSX_SYSROOT` variable in order to work and without it, it silently fails
to generate the files that later on need to be compiled.
This commit will fatal error out of config when building debugserver without
having set CMAKE_OSX_SYSROOT.
---
Full diff: https://github.com/llvm/llvm-project/pull/138020.diff
1 Files Affected:
- (modified) lldb/tools/debugserver/source/CMakeLists.txt (+4)
``diff
diff --git a/lldb/tools/debugserver/source/CMakeLists.txt
b/lldb/tools/debugserver/source/CMakeLists.txt
index 1a433898f6aa4..45b16c74f5197 100644
--- a/lldb/tools/debugserver/source/CMakeLists.txt
+++ b/lldb/tools/debugserver/source/CMakeLists.txt
@@ -154,6 +154,10 @@ endif()
add_definitions(-DLLDB_USE_OS_LOG)
+if(NOT CMAKE_OSX_SYSROOT)
+ message(FATAL_ERROR "debugserver needs the macOS SDK root. Please pass in
-DCMAKE_OSX_SYSROOT in your CMake invocation")
+endif()
+
if(${CMAKE_OSX_SYSROOT} MATCHES ".Internal.sdk$")
message(STATUS "LLDB debugserver energy support is enabled")
add_definitions(-DLLDB_ENERGY)
``
https://github.com/llvm/llvm-project/pull/138020
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang][frontend] Require invocation to construct `CompilerInstance` (PR #137668)
https://github.com/Bigcheese approved this pull request. Makes sense. Every non-test creation of `CompilerInstance` has an associated invocation. https://github.com/llvm/llvm-project/pull/137668 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Error out when building debugserver with CMake 4 (PR #138020)
https://github.com/chelcassanova created
https://github.com/llvm/llvm-project/pull/138020
CMake 4 no longer sets the `CMAKE_OSX_SYSROOT` variable by default. If you've
updated to CMake 4 on macOS (e.g. with brew) and try building LLDB with
CMake/ninja, this will yield an error when building debugserver that clang is
unable to run since it tries to compile files that don't exist.
These files are supposed to be generated by the `mig` process. `mig` needs the
`CMAKE_OSX_SYSROOT` variable in order to work and without it, it silently fails
to generate the files that later on need to be compiled.
This commit will fatal error out of config when building debugserver without
having set CMAKE_OSX_SYSROOT.
>From df5306b9ba433a907795a74f939c283a857f0063 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Mon, 28 Apr 2025 10:28:03 -0700
Subject: [PATCH] [lldb][cmake] Error out when building debugserver with CMake
4
CMake 4 no longer sets the `CMAKE_OSX_SYSROOT` variable by default. If
you've updated to CMake 4 on macOS (e.g. with brew) and try building LLDB with
CMake/ninja, this will yield an error when building debugserver that
clang is unable to run since it tries to compile files that don't exist.
These files are supposed to be generated by the `mig` process. `mig`
needs the `CMAKE_OSX_SYSROOT` variable in order to work and without it,
it silently fails to generate the files that later on need to be
compiled.
This commit will fatal error out of config when building debugserver
without having set CMAKE_OSX_SYSROOT.
---
lldb/tools/debugserver/source/CMakeLists.txt | 4
1 file changed, 4 insertions(+)
diff --git a/lldb/tools/debugserver/source/CMakeLists.txt
b/lldb/tools/debugserver/source/CMakeLists.txt
index 1a433898f6aa4..45b16c74f5197 100644
--- a/lldb/tools/debugserver/source/CMakeLists.txt
+++ b/lldb/tools/debugserver/source/CMakeLists.txt
@@ -154,6 +154,10 @@ endif()
add_definitions(-DLLDB_USE_OS_LOG)
+if(NOT CMAKE_OSX_SYSROOT)
+ message(FATAL_ERROR "debugserver needs the macOS SDK root. Please pass in
-DCMAKE_OSX_SYSROOT in your CMake invocation")
+endif()
+
if(${CMAKE_OSX_SYSROOT} MATCHES ".Internal.sdk$")
message(STATUS "LLDB debugserver energy support is enabled")
add_definitions(-DLLDB_ENERGY)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
@@ -44,6 +44,34 @@ def step_out_with_scripted_plan(self, name):
stop_desc = thread.GetStopDescription(1000)
self.assertIn("Stepping out from", stop_desc, "Got right description")
+def test_step_single_instruction(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan("Steps.StepSingleInstruction")
+self.assertSuccess(err)
+
+# Verify that stepping a single instruction after "foo();" steps into
`foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("foo", frame.GetFunctionName())
+
+def test_step_single_instruction_with_step_over(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan(
+"Steps.StepSingleInstructionWithStepOver"
+)
+self.assertSuccess(err)
+
+# Verify that stepping over an instruction doesn't step into `foo`
+frame = thread.GetFrameAtIndex(0)
+self.assertEqual("main", frame.GetFunctionName())
eronnen wrote:
makes sense, I didn't have any other straightfoward idea for a 100% way to
break on a branch instruction but adding a check is a good idea
https://github.com/llvm/llvm-project/pull/137904
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Error out when building debugserver with CMake 4 (PR #138020)
medismailben wrote: Shouldn't we just pre-populate that cmake variable when it's not set ? That would be a better user experience. https://github.com/llvm/llvm-project/pull/138020 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #137512)
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/137512
>From fd74de70151567d402eb7c0326a6234a21cb2db7 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Sun, 27 Apr 2025 13:48:45 +0200
Subject: [PATCH 1/4] [lldb] add settings to control how synthetic symbol names
are generated
---
lldb/include/lldb/Core/ModuleList.h | 15 +++
lldb/include/lldb/lldb-enumerations.h | 6 ++
lldb/source/Core/CoreProperties.td| 5 +
lldb/source/Core/ModuleList.cpp | 8
lldb/source/Symbol/Symbol.cpp | 13 -
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/Core/ModuleList.h
b/lldb/include/lldb/Core/ModuleList.h
index 909ee08f9ba62..baed175be5313 100644
--- a/lldb/include/lldb/Core/ModuleList.h
+++ b/lldb/include/lldb/Core/ModuleList.h
@@ -67,6 +67,20 @@ static constexpr OptionEnumValueElement
g_auto_download_enum_values[] = {
},
};
+static constexpr OptionEnumValueElement
+g_synthetic_symbols_name_style_values[] = {
+{
+lldb::eSyntheticSymbolsNameStyleIndex,
+"index",
+"Function index style",
+},
+{
+lldb::eSyntheticSymbolsNameStyleFileAddress,
+"file-address",
+"Function file address in module style",
+},
+};
+
class ModuleListProperties : public Properties {
mutable llvm::sys::RWMutex m_symlink_paths_mutex;
PathMappingList m_symlink_paths;
@@ -91,6 +105,7 @@ class ModuleListProperties : public Properties {
bool GetLoadSymbolOnDemand();
lldb::SymbolDownload GetSymbolAutoDownload() const;
+ lldb::SyntheticSymbolsNameStyle GetSyntheticSymbolsNameStyle() const;
PathMappingList GetSymlinkMappings() const;
};
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 6d10cc8bcffcb..26e83cefbe571 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1391,6 +1391,12 @@ enum StopDisassemblyType {
eStopDisassemblyTypeAlways
};
+/// Format to use for unknown symbols.
+enum SyntheticSymbolsNameStyle {
+ eSyntheticSymbolsNameStyleIndex = 0,
+ eSyntheticSymbolsNameStyleFileAddress = 1,
+};
+
} // namespace lldb
#endif // LLDB_LLDB_ENUMERATIONS_H
diff --git a/lldb/source/Core/CoreProperties.td
b/lldb/source/Core/CoreProperties.td
index a1a4e994c3b9c..7eaecb729c36d 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -46,6 +46,11 @@ let Definition = "modulelist" in {
Global,
DefaultFalse,
Desc<"Enable on demand symbol loading in LLDB. LLDB will load debug info
on demand for each module based on various conditions (e.g. matched breakpoint,
resolved stack frame addresses and matched global variables/function symbols in
symbol table) to improve performance. Please refer to docs/use/ondemand.rst for
details.">;
+ def SyntheticSymbolsNameStyle: Property<"synthetic-symbols-name-style",
"Enum">,
+Global,
+DefaultEnumValue<"eSyntheticSymbolsNameStyleIndex">,
+EnumValues<"OptionEnumValues(g_synthetic_symbols_name_style_values)">,
+Desc<"Determines the way synthetic symbol names are generated for unknown
symbols">;
}
let Definition = "debugger" in {
diff --git a/lldb/source/Core/ModuleList.cpp b/lldb/source/Core/ModuleList.cpp
index 6052cc151744d..c48c5bbfb5e92 100644
--- a/lldb/source/Core/ModuleList.cpp
+++ b/lldb/source/Core/ModuleList.cpp
@@ -115,6 +115,14 @@ SymbolDownload
ModuleListProperties::GetSymbolAutoDownload() const {
g_modulelist_properties[idx].default_uint_value));
}
+lldb::SyntheticSymbolsNameStyle
+ModuleListProperties::GetSyntheticSymbolsNameStyle() const {
+ const uint32_t idx = ePropertySyntheticSymbolsNameStyle;
+ return GetPropertyAtIndexAs(
+ idx, static_cast(
+ g_modulelist_properties[idx].default_uint_value));
+}
+
FileSpec ModuleListProperties::GetClangModulesCachePath() const {
const uint32_t idx = ePropertyClangModulesCachePath;
return GetPropertyAtIndexAs(idx, {});
diff --git a/lldb/source/Symbol/Symbol.cpp b/lldb/source/Symbol/Symbol.cpp
index 4828de4fdfa37..825ca5babe28e 100644
--- a/lldb/source/Symbol/Symbol.cpp
+++ b/lldb/source/Symbol/Symbol.cpp
@@ -639,7 +639,18 @@ void Symbol::SynthesizeNameIfNeeded() const {
// breakpoints on them.
llvm::SmallString<256> name;
llvm::raw_svector_ostream os(name);
-os << GetSyntheticSymbolPrefix() << GetID();
+os << GetSyntheticSymbolPrefix();
+switch (ModuleList::GetGlobalModuleListProperties()
+.GetSyntheticSymbolsNameStyle()) {
+case eSyntheticSymbolsNameStyleIndex:
+ os << GetID();
+ break;
+case eSyntheticSymbolsNameStyleFileAddress:
+ os << "_"
+ << llvm::format_hex_no_prefix(
+m_addr_range.GetBaseAddress().GetFileAddress(), 0);
+ break;
+}
m_mangled.SetDemangledName(ConstString(os.str()));
[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #137512)
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/137512
>From fd74de70151567d402eb7c0326a6234a21cb2db7 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Sun, 27 Apr 2025 13:48:45 +0200
Subject: [PATCH 1/5] [lldb] add settings to control how synthetic symbol names
are generated
---
lldb/include/lldb/Core/ModuleList.h | 15 +++
lldb/include/lldb/lldb-enumerations.h | 6 ++
lldb/source/Core/CoreProperties.td| 5 +
lldb/source/Core/ModuleList.cpp | 8
lldb/source/Symbol/Symbol.cpp | 13 -
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/Core/ModuleList.h
b/lldb/include/lldb/Core/ModuleList.h
index 909ee08f9ba62..baed175be5313 100644
--- a/lldb/include/lldb/Core/ModuleList.h
+++ b/lldb/include/lldb/Core/ModuleList.h
@@ -67,6 +67,20 @@ static constexpr OptionEnumValueElement
g_auto_download_enum_values[] = {
},
};
+static constexpr OptionEnumValueElement
+g_synthetic_symbols_name_style_values[] = {
+{
+lldb::eSyntheticSymbolsNameStyleIndex,
+"index",
+"Function index style",
+},
+{
+lldb::eSyntheticSymbolsNameStyleFileAddress,
+"file-address",
+"Function file address in module style",
+},
+};
+
class ModuleListProperties : public Properties {
mutable llvm::sys::RWMutex m_symlink_paths_mutex;
PathMappingList m_symlink_paths;
@@ -91,6 +105,7 @@ class ModuleListProperties : public Properties {
bool GetLoadSymbolOnDemand();
lldb::SymbolDownload GetSymbolAutoDownload() const;
+ lldb::SyntheticSymbolsNameStyle GetSyntheticSymbolsNameStyle() const;
PathMappingList GetSymlinkMappings() const;
};
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 6d10cc8bcffcb..26e83cefbe571 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1391,6 +1391,12 @@ enum StopDisassemblyType {
eStopDisassemblyTypeAlways
};
+/// Format to use for unknown symbols.
+enum SyntheticSymbolsNameStyle {
+ eSyntheticSymbolsNameStyleIndex = 0,
+ eSyntheticSymbolsNameStyleFileAddress = 1,
+};
+
} // namespace lldb
#endif // LLDB_LLDB_ENUMERATIONS_H
diff --git a/lldb/source/Core/CoreProperties.td
b/lldb/source/Core/CoreProperties.td
index a1a4e994c3b9c..7eaecb729c36d 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -46,6 +46,11 @@ let Definition = "modulelist" in {
Global,
DefaultFalse,
Desc<"Enable on demand symbol loading in LLDB. LLDB will load debug info
on demand for each module based on various conditions (e.g. matched breakpoint,
resolved stack frame addresses and matched global variables/function symbols in
symbol table) to improve performance. Please refer to docs/use/ondemand.rst for
details.">;
+ def SyntheticSymbolsNameStyle: Property<"synthetic-symbols-name-style",
"Enum">,
+Global,
+DefaultEnumValue<"eSyntheticSymbolsNameStyleIndex">,
+EnumValues<"OptionEnumValues(g_synthetic_symbols_name_style_values)">,
+Desc<"Determines the way synthetic symbol names are generated for unknown
symbols">;
}
let Definition = "debugger" in {
diff --git a/lldb/source/Core/ModuleList.cpp b/lldb/source/Core/ModuleList.cpp
index 6052cc151744d..c48c5bbfb5e92 100644
--- a/lldb/source/Core/ModuleList.cpp
+++ b/lldb/source/Core/ModuleList.cpp
@@ -115,6 +115,14 @@ SymbolDownload
ModuleListProperties::GetSymbolAutoDownload() const {
g_modulelist_properties[idx].default_uint_value));
}
+lldb::SyntheticSymbolsNameStyle
+ModuleListProperties::GetSyntheticSymbolsNameStyle() const {
+ const uint32_t idx = ePropertySyntheticSymbolsNameStyle;
+ return GetPropertyAtIndexAs(
+ idx, static_cast(
+ g_modulelist_properties[idx].default_uint_value));
+}
+
FileSpec ModuleListProperties::GetClangModulesCachePath() const {
const uint32_t idx = ePropertyClangModulesCachePath;
return GetPropertyAtIndexAs(idx, {});
diff --git a/lldb/source/Symbol/Symbol.cpp b/lldb/source/Symbol/Symbol.cpp
index 4828de4fdfa37..825ca5babe28e 100644
--- a/lldb/source/Symbol/Symbol.cpp
+++ b/lldb/source/Symbol/Symbol.cpp
@@ -639,7 +639,18 @@ void Symbol::SynthesizeNameIfNeeded() const {
// breakpoints on them.
llvm::SmallString<256> name;
llvm::raw_svector_ostream os(name);
-os << GetSyntheticSymbolPrefix() << GetID();
+os << GetSyntheticSymbolPrefix();
+switch (ModuleList::GetGlobalModuleListProperties()
+.GetSyntheticSymbolsNameStyle()) {
+case eSyntheticSymbolsNameStyleIndex:
+ os << GetID();
+ break;
+case eSyntheticSymbolsNameStyleFileAddress:
+ os << "_"
+ << llvm::format_hex_no_prefix(
+m_addr_range.GetBaseAddress().GetFileAddress(), 0);
+ break;
+}
m_mangled.SetDemangledName(ConstString(os.str()));
[Lldb-commits] [lldb] [lldb][test] Test all libcxxabi demangler test-cases against TrackingOutputBuffer (PR #137793)
Michael137 wrote: Proposed moving the tests here: https://github.com/llvm/llvm-project/pull/137947 https://github.com/llvm/llvm-project/pull/137793 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix raciness in launch and attach tests (PR #137920)
https://github.com/labath commented: Someone once told me: "Whatever problem you're trying to solve, if you're using atomics, now you've got two problems." I can't say I've always followed that advice, but I do think that atomics are rarely the right solution to a problem. And I think this is a good example of that. What you want is not to suppress *a* event (whatever it might be). You want to suppress a very specific event (that is supposed to be generated by the action you're about to perform). That means that something needs to ensure that the other thread reads this flag after you've generated the event. If that's true, then you already have a happens-before relationship and the atomic is not necessary. If it isn't (there is no happens-before), then the atomic will not help. That said, why is ConnectRemote generating a stopped event in synchronous mode? Maybe that's the bug we should fix? https://github.com/llvm/llvm-project/pull/137920 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
@@ -153,10 +173,37 @@ constexpr llvm::StringRef lookupStrings[] = {
"${target.file.fullpath}",
"${var.dummy-var-to-test-wildcard}"};
-TEST(FormatEntity, LookupAllEntriesInTree) {
+TEST_F(FormatEntityTest, LookupAllEntriesInTree) {
for (const llvm::StringRef testString : lookupStrings) {
Entry e;
EXPECT_TRUE(FormatEntity::Parse(testString, e).Success())
<< "Formatting " << testString << " did not succeed";
}
}
+
+TEST_F(FormatEntityTest, Scope) {
+ // Scope with one alternative.
+ EXPECT_THAT_EXPECTED(Format("{${frame.pc}|foo}"), HasValue("foo"));
+
+ // Scope with multiple alternatives.
+ EXPECT_THAT_EXPECTED(Format("{${frame.pc}|${function.name}|foo}"),
+ HasValue("foo"));
+
+ // Escaped pipe inside a scope.
+ EXPECT_THAT_EXPECTED(Format("{foo\\|bar}"), HasValue("foo|bar"));
+
+ // Unescaped pipe outside a scope.
+ EXPECT_THAT_EXPECTED(Format("foo|bar"), HasValue("foo|bar"));
+
+ // Nested scopes. Note that scopes always resolve.
+ EXPECT_THAT_EXPECTED(Format("{{${frame.pc}|foo}|{bar}}"), HasValue("foo"));
+ EXPECT_THAT_EXPECTED(Format("{{${frame.pc}}|{bar}}"), HasValue(""));
labath wrote:
That would break literally every existing use of scopes because the only reason
to use them was to make expansion failures non-fatal. I'm not saying we can't
do that, but I think that's what it is. We could try to split hairs and say
this only applies to scopes with more than one alternative, but I don't know if
it's worth it. I suppose it might be used to write something like `{common
prefix {${foo}|${bar}}| alternative prefix}`, but I don't know if there's a
realistic use case for that.
https://github.com/llvm/llvm-project/pull/137751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
@@ -8,16 +8,36 @@
#include "lldb/Core/FormatEntity.h"
#include "lldb/Utility/Status.h"
-
+#include "lldb/Utility/StreamString.h"
#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Error.h"
#include "gtest/gtest.h"
using namespace lldb_private;
+using namespace llvm;
using Definition = FormatEntity::Entry::Definition;
using Entry = FormatEntity::Entry;
-TEST(FormatEntityTest, DefinitionConstructionNameAndType) {
+namespace {
+class FormatEntityTest : public ::testing::Test {
+public:
+ Expected Format(StringRef format_str) {
labath wrote:
As there's (still) no state, you could just make this a static helper function.
```suggestion
static Expected Format(StringRef format_str) {
```
https://github.com/llvm/llvm-project/pull/137751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
https://github.com/labath commented: Seems legit, I'll let you and Michael figure out the failure mode for alternatives. https://github.com/llvm/llvm-project/pull/137751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/137751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Test all libcxxabi demangler test-cases against TrackingOutputBuffer (PR #137793)
labath wrote: Including a random file from the libc++ subproject sounds like a bad idea to me. I certainly hope we don't have a precedent for that. For the way you're using these files (as a gtest unit test), I think it'd be best if the tests were in `llvm/include/llvm/Testing/Demangle`. That would most likely be a problem for libc++ since they don't want to depend on llvm (even the demangler is copied into the llvm tree instead of being reused somehow). According to [this](https://github.com/llvm/llvm-project/blob/f62f36b91de684ddfe129532e3a5086009b16f34/libcxxabi/src/demangle/README.txt#L57), it *might* be possible to move the test to llvm and then you could do what I suggest. I don't know what's the amount of wishful thinking in that comment though... Just a note, that if you do decide to copy the tests, it may be better to just copy the inputs (mangled) and then compare the "normal" demangled names with the ones you reconstructed. This avoids needing to update two places in case e.g. the demangler produces extra spaces somewhere. https://github.com/llvm/llvm-project/pull/137793 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix block address resolution for functions in multiple sections (PR #137955)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
Continuing the theme from #116777 and #124931, this patch
ensures we compute the correct address when a functions is spread across
multiple sections. Due to this, it's not sufficient to adjust the offset in the
section+offset pair (Address::Slide). We must actually slide the file offset
and then recompute the section using the result.
---
Full diff: https://github.com/llvm/llvm-project/pull/137955.diff
2 Files Affected:
- (modified) lldb/source/Symbol/Block.cpp (+21-18)
- (added) lldb/test/Shell/Commands/command-disassemble-sections.s (+102)
``diff
diff --git a/lldb/source/Symbol/Block.cpp b/lldb/source/Symbol/Block.cpp
index 9d01293ea64e0..b630b148a90c9 100644
--- a/lldb/source/Symbol/Block.cpp
+++ b/lldb/source/Symbol/Block.cpp
@@ -283,39 +283,42 @@ uint32_t Block::GetRangeIndexContainingAddress(const
Address &addr) {
return m_ranges.FindEntryIndexThatContains(file_addr - func_file_addr);
}
+static AddressRange ToAddressRange(const Address &func_addr,
+ const Block::Range &range) {
+ assert(func_addr.GetModule());
+ return AddressRange(func_addr.GetFileAddress() + range.base, range.size,
+ func_addr.GetModule()->GetSectionList());
+}
+
bool Block::GetRangeAtIndex(uint32_t range_idx, AddressRange &range) {
if (range_idx >= m_ranges.GetSize())
return false;
- Function &function = GetFunction();
- const Range &vm_range = m_ranges.GetEntryRef(range_idx);
- range.GetBaseAddress() = function.GetAddress();
- range.GetBaseAddress().Slide(vm_range.GetRangeBase());
- range.SetByteSize(vm_range.GetByteSize());
+ Address addr = GetFunction().GetAddress();
+ if (!addr.GetModule())
+return false;
+
+ range = ToAddressRange(addr, m_ranges.GetEntryRef(range_idx));
return true;
}
AddressRanges Block::GetRanges() {
+ Address addr = GetFunction().GetAddress();
+ if (!addr.GetModule())
+return {};
+
AddressRanges ranges;
- Function &function = GetFunction();
- for (size_t i = 0, e = m_ranges.GetSize(); i < e; ++i) {
-ranges.emplace_back();
-auto &range = ranges.back();
-const Range &vm_range = m_ranges.GetEntryRef(i);
-range.GetBaseAddress() = function.GetAddress();
-range.GetBaseAddress().Slide(vm_range.GetRangeBase());
-range.SetByteSize(vm_range.GetByteSize());
- }
+ for (size_t i = 0, e = m_ranges.GetSize(); i < e; ++i)
+ranges.push_back(ToAddressRange(addr, m_ranges.GetEntryRef(i)));
return ranges;
}
bool Block::GetStartAddress(Address &addr) {
- if (m_ranges.IsEmpty())
+ Address func_addr = GetFunction().GetAddress();
+ if (!func_addr.GetModule() || m_ranges.IsEmpty())
return false;
- Function &function = GetFunction();
- addr = function.GetAddress();
- addr.Slide(m_ranges.GetEntryRef(0).GetRangeBase());
+ addr = ToAddressRange(func_addr, m_ranges.GetEntryRef(0)).GetBaseAddress();
return true;
}
diff --git a/lldb/test/Shell/Commands/command-disassemble-sections.s
b/lldb/test/Shell/Commands/command-disassemble-sections.s
new file mode 100644
index 0..d7ade39241b22
--- /dev/null
+++ b/lldb/test/Shell/Commands/command-disassemble-sections.s
@@ -0,0 +1,102 @@
+# REQUIRES: x86, lld
+
+# RUN: split-file %s %t
+# RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux %t/file.s -o %t/file.o
+# RUN: ld.lld %t/file.o -o %t/file.out -T %t/file.lds
+# RUN: %lldb %t/file.out -o "disassemble --name func1" -o exit | FileCheck %s
+
+# CHECK: (lldb) disassemble --name func1
+# CHECK: file.out`func1:
+# CHECK-NEXT: file.out[0x0] <+0>: int$0x2a
+# CHECK: file.out`func1:
+# CHECK-NEXT: file.out[0x1000] <+4096>: int$0x2f
+
+
+#--- file.lds
+PHDRS {
+ text1 PT_LOAD;
+ text2 PT_LOAD;
+}
+SECTIONS {
+ . = 0;
+ .text.part1 : { *(.text.part1) } :text1
+ .text.part2 : { *(.text.part2) } :text2
+}
+
+#--- file.s
+.section.text.part1,"ax",@progbits
+.p2align 12
+func1:
+int $42
+.Lfunc1_end:
+
+.section.text.part2,"ax",@progbits
+.p2align 12
+func1.__part.1:
+int $47
+.Lfunc1.__part.1_end:
+
+
+
+.section.debug_abbrev,"",@progbits
+.byte 1 # Abbreviation Code
+.byte 17 # DW_TAG_compile_unit
+.byte 1 # DW_CHILDREN_yes
+.byte 37 # DW_AT_producer
+.byte 8 # DW_FORM_string
+.byte 19 # DW_AT_language
+.byte 5 # DW_FORM_data2
+.byte 17 # DW_AT_low_pc
+.byte 1 # DW_FORM_addr
+.byte 85 # DW_AT_ranges
+.byte 23 # DW_FORM_sec_offset
+.byte 0
[Lldb-commits] [lldb] [lldb] Fix block address resolution for functions in multiple sections (PR #137955)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/137955
Continuing the theme from #116777 and #124931, this patch ensures we compute
the correct address when a functions is spread across multiple sections. Due to
this, it's not sufficient to adjust the offset in the section+offset pair
(Address::Slide). We must actually slide the file offset and then recompute the
section using the result.
>From 9a6a3130942ac3ff90dc3e2eb83748700bf136ae Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 29 Apr 2025 16:27:11 +0200
Subject: [PATCH] [lldb] Fix block address resolution for functions in multiple
sections
Continuing the theme from #116777 and #124931, this patch ensures we
compute the correct address when a functions is spread across multiple
sections. Due to this, it's not sufficient to adjust the offset in the
section+offset pair (Address::Slide). We must actually slide the file
offset and then recompute the section using the result.
---
lldb/source/Symbol/Block.cpp | 39 +++
.../Commands/command-disassemble-sections.s | 102 ++
2 files changed, 123 insertions(+), 18 deletions(-)
create mode 100644 lldb/test/Shell/Commands/command-disassemble-sections.s
diff --git a/lldb/source/Symbol/Block.cpp b/lldb/source/Symbol/Block.cpp
index 9d01293ea64e0..b630b148a90c9 100644
--- a/lldb/source/Symbol/Block.cpp
+++ b/lldb/source/Symbol/Block.cpp
@@ -283,39 +283,42 @@ uint32_t Block::GetRangeIndexContainingAddress(const
Address &addr) {
return m_ranges.FindEntryIndexThatContains(file_addr - func_file_addr);
}
+static AddressRange ToAddressRange(const Address &func_addr,
+ const Block::Range &range) {
+ assert(func_addr.GetModule());
+ return AddressRange(func_addr.GetFileAddress() + range.base, range.size,
+ func_addr.GetModule()->GetSectionList());
+}
+
bool Block::GetRangeAtIndex(uint32_t range_idx, AddressRange &range) {
if (range_idx >= m_ranges.GetSize())
return false;
- Function &function = GetFunction();
- const Range &vm_range = m_ranges.GetEntryRef(range_idx);
- range.GetBaseAddress() = function.GetAddress();
- range.GetBaseAddress().Slide(vm_range.GetRangeBase());
- range.SetByteSize(vm_range.GetByteSize());
+ Address addr = GetFunction().GetAddress();
+ if (!addr.GetModule())
+return false;
+
+ range = ToAddressRange(addr, m_ranges.GetEntryRef(range_idx));
return true;
}
AddressRanges Block::GetRanges() {
+ Address addr = GetFunction().GetAddress();
+ if (!addr.GetModule())
+return {};
+
AddressRanges ranges;
- Function &function = GetFunction();
- for (size_t i = 0, e = m_ranges.GetSize(); i < e; ++i) {
-ranges.emplace_back();
-auto &range = ranges.back();
-const Range &vm_range = m_ranges.GetEntryRef(i);
-range.GetBaseAddress() = function.GetAddress();
-range.GetBaseAddress().Slide(vm_range.GetRangeBase());
-range.SetByteSize(vm_range.GetByteSize());
- }
+ for (size_t i = 0, e = m_ranges.GetSize(); i < e; ++i)
+ranges.push_back(ToAddressRange(addr, m_ranges.GetEntryRef(i)));
return ranges;
}
bool Block::GetStartAddress(Address &addr) {
- if (m_ranges.IsEmpty())
+ Address func_addr = GetFunction().GetAddress();
+ if (!func_addr.GetModule() || m_ranges.IsEmpty())
return false;
- Function &function = GetFunction();
- addr = function.GetAddress();
- addr.Slide(m_ranges.GetEntryRef(0).GetRangeBase());
+ addr = ToAddressRange(func_addr, m_ranges.GetEntryRef(0)).GetBaseAddress();
return true;
}
diff --git a/lldb/test/Shell/Commands/command-disassemble-sections.s
b/lldb/test/Shell/Commands/command-disassemble-sections.s
new file mode 100644
index 0..d7ade39241b22
--- /dev/null
+++ b/lldb/test/Shell/Commands/command-disassemble-sections.s
@@ -0,0 +1,102 @@
+# REQUIRES: x86, lld
+
+# RUN: split-file %s %t
+# RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux %t/file.s -o %t/file.o
+# RUN: ld.lld %t/file.o -o %t/file.out -T %t/file.lds
+# RUN: %lldb %t/file.out -o "disassemble --name func1" -o exit | FileCheck %s
+
+# CHECK: (lldb) disassemble --name func1
+# CHECK: file.out`func1:
+# CHECK-NEXT: file.out[0x0] <+0>: int$0x2a
+# CHECK: file.out`func1:
+# CHECK-NEXT: file.out[0x1000] <+4096>: int$0x2f
+
+
+#--- file.lds
+PHDRS {
+ text1 PT_LOAD;
+ text2 PT_LOAD;
+}
+SECTIONS {
+ . = 0;
+ .text.part1 : { *(.text.part1) } :text1
+ .text.part2 : { *(.text.part2) } :text2
+}
+
+#--- file.s
+.section.text.part1,"ax",@progbits
+.p2align 12
+func1:
+int $42
+.Lfunc1_end:
+
+.section.text.part2,"ax",@progbits
+.p2align 12
+func1.__part.1:
+int $47
+.Lfunc1.__part.1_end:
+
+
+
+.section.debug_abbrev,"",@progbits
+.byte 1 # Abbreviation Code
+.byte 17 # DW_TAG_compile_unit
+.byte 1
[Lldb-commits] [lldb] [lldb] Fix block address resolution for functions in multiple sections (PR #137955)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/137955 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix block address resolution for functions in multiple sections (PR #137955)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/137955 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #137512)
eronnen wrote: Cool, changed the patch to have it by default https://github.com/llvm/llvm-project/pull/137512 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix raciness in launch and attach tests (PR #137920)
https://github.com/JDevlieghere updated
https://github.com/llvm/llvm-project/pull/137920
>From 1bdae983cdde60453c213a8086033c84dce3fb2d Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Wed, 30 Apr 2025 17:19:49 -0700
Subject: [PATCH 1/2] [lldb-dap] Fix raciness in launch and attach tests
#137920
---
.../test/tools/lldb-dap/lldbdap_testcase.py | 2 +-
.../tools/lldb-dap/attach/TestDAP_attach.py | 1 -
.../attach/TestDAP_attachByPortNum.py | 1 -
lldb/tools/lldb-dap/DAP.cpp | 4 ++-
lldb/tools/lldb-dap/DAP.h | 11 +++
.../lldb-dap/Handler/AttachRequestHandler.cpp | 33 +--
.../ConfigurationDoneRequestHandler.cpp | 18 ++
.../Handler/InitializeRequestHandler.cpp | 21
.../tools/lldb-dap/Handler/RequestHandler.cpp | 21 +++-
lldb/tools/lldb-dap/Handler/RequestHandler.h | 5 ++-
10 files changed, 88 insertions(+), 29 deletions(-)
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index ee5272850b9a8..0d81b7d80102f 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -103,7 +103,7 @@ def verify_breakpoint_hit(self, breakpoint_ids):
match_desc = "breakpoint %s." % (breakpoint_id)
if match_desc in description:
return
-self.assertTrue(False, "breakpoint not hit")
+self.assertTrue(False, f"breakpoint not hit:
stopped_events={stopped_events}")
def verify_stop_exception_info(self, expected_description,
timeout=timeoutval):
"""Wait for the process we are debugging to stop, and verify the stop
diff --git a/lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
b/lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
index 6f70316821c8c..dcdfada2ff4c2 100644
--- a/lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
+++ b/lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
@@ -25,7 +25,6 @@ def spawn_and_wait(program, delay):
process.wait()
-@skipIf
class TestDAP_attach(lldbdap_testcase.DAPTestCaseBase):
def set_and_hit_breakpoint(self, continueToExit=True):
source = "main.c"
diff --git a/lldb/test/API/tools/lldb-dap/attach/TestDAP_attachByPortNum.py
b/lldb/test/API/tools/lldb-dap/attach/TestDAP_attachByPortNum.py
index 51f62b79f3f4f..152e504af6d14 100644
--- a/lldb/test/API/tools/lldb-dap/attach/TestDAP_attachByPortNum.py
+++ b/lldb/test/API/tools/lldb-dap/attach/TestDAP_attachByPortNum.py
@@ -19,7 +19,6 @@
import socket
-@skip
class TestDAP_attachByPortNum(lldbdap_testcase.DAPTestCaseBase):
default_timeout = 20
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 4cb0d8e49004c..e3140a1231b00 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -85,7 +85,9 @@ DAP::DAP(Log *log, const ReplMode default_repl_mode,
exception_breakpoints(), focus_tid(LLDB_INVALID_THREAD_ID),
stop_at_entry(false), is_attach(false),
restarting_process_id(LLDB_INVALID_PROCESS_ID),
- configuration_done_sent(false), waiting_for_run_in_terminal(false),
+ configuration_done_sent(false),
+ first_stop_state(FirstStopState::NoStopEvent),
+ waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
reverse_request_seq(0), repl_mode(default_repl_mode) {
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 88eedb0860cf1..7a50b0f682fe3 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -189,6 +189,17 @@ struct DAP {
// the old process here so we can detect this case and keep running.
lldb::pid_t restarting_process_id;
bool configuration_done_sent;
+
+ enum class FirstStopState {
+NoStopEvent,
+PendingStopEvent,
+IgnoredStopEvent,
+ };
+ std::mutex first_stop_mutex;
+ std::condition_variable first_stop_cv;
+ FirstStopState first_stop_state;
+
+ bool ignore_next_stop;
llvm::StringMap> request_handlers;
bool waiting_for_run_in_terminal;
ProgressEventReporter progress_event_reporter;
diff --git a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
index 7084d30f2625b..c6c1b86922fc2 100644
--- a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
@@ -158,8 +158,15 @@ void AttachRequestHandler::operator()(const
llvm::json::Object &request) const {
std::string connect_url =
llvm::formatv("connect://{0}:", gdb_remote_hostname);
connect_url += std::to_string(gdb_remote_port);
-dap.target.ConnectRemote(listener, connect_url.c_str(), "gdb-remote",
-
[Lldb-commits] [lldb] [lldb][cmake] Set `CMAKE_OSX_SYSROOT` when building debugserver with CMake 4 (PR #138020)
@@ -154,6 +154,20 @@ endif()
add_definitions(-DLLDB_USE_OS_LOG)
+if(NOT CMAKE_OSX_SYSROOT)
+ execute_process(COMMAND xcodebuild -version -sdk macosx Path
+OUTPUT_VARIABLE SDKROOT
+ERROR_QUIET
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+ if(NOT EXISTS ${SDKROOT})
+message(FATAL_ERROR "Unable to obtain macOS SDK root, debugserver cannot
be built.")
+ endif()
+
+ message(STATUS "Using macOS SDK root: ${SDKROOT}")
+ set(CMAKE_OSX_SYSROOT ${SDKROOT})
+endif()
JDevlieghere wrote:
I don't think we should try to compute `CMAKE_OSX_SYSROOT` ourselves. If we
need an `-isysroot` for the `mig` invocation, it's fine to compute it, but we
shouldn't reuse `CMAKE_OSX_SYSROOT` for that. The
[documentation](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_SYSROOT.html)
before the `project()` call.
Here's what I think we should do instead:
```
if (CMAKE_OSX_SYSROOT)
set(MIG_SYSROOT ${CMAKE_OSX_SYSROOT})
else()
# Set the sysroot based on the output of `xcrun --show-sdk-path`
endif()
```
And then the mig invocation should use `${MIG_SYSROOT}` instead of
`${CMAKE_OSX_SYSROOT}`.
`xcrun` is the usual way to get the SDK path and by not specifying the SDK, it
will honor the usual ways of changing the SDK (which matters to us internally).
https://github.com/llvm/llvm-project/pull/138020
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Set `CMAKE_OSX_SYSROOT` when building debugserver with CMake 4 (PR #138020)
https://github.com/JDevlieghere requested changes to this pull request. https://github.com/llvm/llvm-project/pull/138020 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Set `CMAKE_OSX_SYSROOT` when building debugserver with CMake 4 (PR #138020)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/138020 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)
https://github.com/slydiman edited https://github.com/llvm/llvm-project/pull/137978 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/137904
>From b901b71abbaac768e67913cdbc15da2337c8bb03 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Wed, 30 Apr 2025 02:00:44 +0200
Subject: [PATCH 1/3] Expose QueueThreadPlanForStepSingleInstruction function
to SBThreadPlan
---
lldb/include/lldb/API/SBThreadPlan.h | 4
lldb/source/API/SBThreadPlan.cpp | 31
2 files changed, 35 insertions(+)
diff --git a/lldb/include/lldb/API/SBThreadPlan.h
b/lldb/include/lldb/API/SBThreadPlan.h
index d02ab80f76a76..ce1a1078d69b9 100644
--- a/lldb/include/lldb/API/SBThreadPlan.h
+++ b/lldb/include/lldb/API/SBThreadPlan.h
@@ -105,6 +105,10 @@ class LLDB_API SBThreadPlan {
SBThreadPlan QueueThreadPlanForStepOut(uint32_t frame_idx_to_step_to,
bool first_insn, SBError &error);
+ SBThreadPlan QueueThreadPlanForStepSingleInstruction(bool step_over);
+ SBThreadPlan QueueThreadPlanForStepSingleInstruction(bool step_over,
+ SBError &error);
+
SBThreadPlan QueueThreadPlanForRunToAddress(SBAddress address);
SBThreadPlan QueueThreadPlanForRunToAddress(SBAddress address,
SBError &error);
diff --git a/lldb/source/API/SBThreadPlan.cpp b/lldb/source/API/SBThreadPlan.cpp
index 083a050de8a38..a85afbb043875 100644
--- a/lldb/source/API/SBThreadPlan.cpp
+++ b/lldb/source/API/SBThreadPlan.cpp
@@ -325,6 +325,37 @@ SBThreadPlan::QueueThreadPlanForStepOut(uint32_t
frame_idx_to_step_to,
return SBThreadPlan();
}
+SBThreadPlan
+SBThreadPlan::QueueThreadPlanForStepSingleInstruction(bool step_over) {
+ LLDB_INSTRUMENT_VA(this, step_over);
+
+ SBError error;
+ return QueueThreadPlanForStepSingleInstruction(step_over, error);
+}
+
+SBThreadPlan
+SBThreadPlan::QueueThreadPlanForStepSingleInstruction(bool step_over,
+ SBError &error) {
+ LLDB_INSTRUMENT_VA(this, step_over, error);
+
+ ThreadPlanSP thread_plan_sp(GetSP());
+ if (thread_plan_sp) {
+Status plan_status;
+SBThreadPlan plan(
+thread_plan_sp->GetThread().QueueThreadPlanForStepSingleInstruction(
+step_over, false, false, plan_status));
+
+if (plan_status.Fail())
+ error.SetErrorString(plan_status.AsCString());
+else
+ plan.GetSP()->SetPrivate(true);
+
+return plan;
+ }
+
+ return SBThreadPlan();
+}
+
SBThreadPlan
SBThreadPlan::QueueThreadPlanForRunToAddress(SBAddress sb_address) {
LLDB_INSTRUMENT_VA(this, sb_address);
>From 8d8f4d7edbff13de7f07853700ab717ef275e3da Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Wed, 30 Apr 2025 09:37:32 +0200
Subject: [PATCH 2/3] Add API tests for QueueThreadPlanForStepSingleInstruction
---
.../functionalities/step_scripted/Steps.py| 16 +++
.../step_scripted/TestStepScripted.py | 28 +++
.../API/functionalities/step_scripted/main.c | 2 +-
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/lldb/test/API/functionalities/step_scripted/Steps.py
b/lldb/test/API/functionalities/step_scripted/Steps.py
index 3325dba753657..e9e0fae1b14be 100644
--- a/lldb/test/API/functionalities/step_scripted/Steps.py
+++ b/lldb/test/API/functionalities/step_scripted/Steps.py
@@ -45,6 +45,22 @@ def queue_child_thread_plan(self):
return self.thread_plan.QueueThreadPlanForStepScripted("Steps.StepOut")
+class StepSingleInstruction(StepWithChild):
+def __init__(self, thread_plan, dict):
+super().__init__(thread_plan)
+
+def queue_child_thread_plan(self):
+return self.thread_plan.QueueThreadPlanForStepSingleInstruction(False)
+
+
+class StepSingleInstructionWithStepOver(StepWithChild):
+def __init__(self, thread_plan, dict):
+super().__init__(thread_plan)
+
+def queue_child_thread_plan(self):
+return self.thread_plan.QueueThreadPlanForStepSingleInstruction(True)
+
+
# This plan does a step-over until a variable changes value.
class StepUntil(StepWithChild):
def __init__(self, thread_plan, args_data):
diff --git a/lldb/test/API/functionalities/step_scripted/TestStepScripted.py
b/lldb/test/API/functionalities/step_scripted/TestStepScripted.py
index 53901718019f9..f65c366a09e87 100644
--- a/lldb/test/API/functionalities/step_scripted/TestStepScripted.py
+++ b/lldb/test/API/functionalities/step_scripted/TestStepScripted.py
@@ -44,6 +44,34 @@ def step_out_with_scripted_plan(self, name):
stop_desc = thread.GetStopDescription(1000)
self.assertIn("Stepping out from", stop_desc, "Got right description")
+def test_step_single_instruction(self):
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Break on foo call", self.main_source_file
+)
+
+err = thread.StepUsingScriptedThreadPlan("Steps.StepSingleInstruction")
+se
[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #137512)
eronnen wrote: Currently not, waiting for https://github.com/llvm/llvm-project/issues/137382 https://github.com/llvm/llvm-project/pull/137512 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Error out when building debugserver with CMake 4 (PR #138020)
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/138020
>From 4e7c20930b3f8bb0b8d4503544d278d1a561f0fd Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Mon, 28 Apr 2025 10:28:03 -0700
Subject: [PATCH] [lldb][cmake] Error out when building debugserver with CMake
4
CMake 4 no longer sets the `CMAKE_OSX_SYSROOT` variable by default. If
you've updated to CMake 4 on macOS (e.g. with brew) and try building LLDB with
CMake/ninja, this will yield an error when building debugserver that
clang is unable to run since it tries to compile files that don't exist.
These files are supposed to be generated by the `mig` process. `mig`
needs the `CMAKE_OSX_SYSROOT` variable in order to work and without it,
it silently fails to generate the files that later on need to be
compiled.
This commit will fatal error out of config when building debugserver
without having set CMAKE_OSX_SYSROOT.
---
lldb/tools/debugserver/source/CMakeLists.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/lldb/tools/debugserver/source/CMakeLists.txt
b/lldb/tools/debugserver/source/CMakeLists.txt
index 1a433898f6aa4..bf40a3fb492ac 100644
--- a/lldb/tools/debugserver/source/CMakeLists.txt
+++ b/lldb/tools/debugserver/source/CMakeLists.txt
@@ -154,6 +154,20 @@ endif()
add_definitions(-DLLDB_USE_OS_LOG)
+if(NOT CMAKE_OSX_SYSROOT)
+ execute_process(COMMAND xcodebuild -version -sdk macosx Path
+OUTPUT_VARIABLE SDKROOT
+ERROR_QUIET
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+ if(NOT EXISTS ${SDKROOT})
+message(FATAL_ERROR "Unable to obtain macOS SDK root, debugserver cannot
be built.")
+ endif()
+
+ message(STATUS "Using macOS SDK root: ${SDKROOT}")
+ set(CMAKE_OSX_SYSROOT ${SDKROOT})
+endif()
+
if(${CMAKE_OSX_SYSROOT} MATCHES ".Internal.sdk$")
message(STATUS "LLDB debugserver energy support is enabled")
add_definitions(-DLLDB_ENERGY)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][cmake] Error out when building debugserver with CMake 4 (PR #138020)
chelcassanova wrote: Just updated the patch to set the `CMAKE_OSX_SYSROOT` variable. https://github.com/llvm/llvm-project/pull/138020 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 1495d13 - [lldb-dap] Add an RAII helper for synchronous mode (NFC) (#137900)
Author: Jonas Devlieghere
Date: 2025-04-30T15:18:32-07:00
New Revision: 1495d132db1d26b086d2ea6b1b9c397bf4ea4a7d
URL:
https://github.com/llvm/llvm-project/commit/1495d132db1d26b086d2ea6b1b9c397bf4ea4a7d
DIFF:
https://github.com/llvm/llvm-project/commit/1495d132db1d26b086d2ea6b1b9c397bf4ea4a7d.diff
LOG: [lldb-dap] Add an RAII helper for synchronous mode (NFC) (#137900)
While debugging the flakiness of the launch and attach tests, I noticed
that we have some places in lldb-dap where we put the debugger in
synchronous mode and have an early exit, that would leave the debugger
in this state. This PR introduces an RAII helper to avoid such mistakes.
Added:
Modified:
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
lldb/tools/lldb-dap/Handler/RequestHandler.cpp
lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp
lldb/tools/lldb-dap/LLDBUtils.cpp
lldb/tools/lldb-dap/LLDBUtils.h
Removed:
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index b593353110787..4cb0d8e49004c 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -820,12 +820,12 @@ llvm::Error DAP::Disconnect(bool terminateDebuggee) {
case lldb::eStateCrashed:
case lldb::eStateSuspended:
case lldb::eStateStopped:
- case lldb::eStateRunning:
-debugger.SetAsync(false);
+ case lldb::eStateRunning: {
+ScopeSyncMode scope_sync_mode(debugger);
error = terminateDebuggee ? process.Kill() : process.Detach();
-debugger.SetAsync(true);
break;
}
+ }
SendTerminatedEvent();
diff --git a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
index 3ef87cbef873c..7084d30f2625b 100644
--- a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
@@ -9,6 +9,7 @@
#include "DAP.h"
#include "EventHelper.h"
#include "JSONUtils.h"
+#include "LLDBUtils.h"
#include "RequestHandler.h"
#include "lldb/API/SBListener.h"
#include "llvm/Support/FileSystem.h"
@@ -138,9 +139,11 @@ void AttachRequestHandler::operator()(const
llvm::json::Object &request) const {
}
if (attachCommands.empty()) {
// No "attachCommands", just attach normally.
+
// Disable async events so the attach will be successful when we return
from
// the launch call and the launch will happen synchronously
-dap.debugger.SetAsync(false);
+ScopeSyncMode scope_sync_mode(dap.debugger);
+
if (core_file.empty()) {
if ((pid != LLDB_INVALID_PROCESS_ID) &&
(gdb_remote_port != invalid_port)) {
@@ -161,10 +164,9 @@ void AttachRequestHandler::operator()(const
llvm::json::Object &request) const {
// Attach by process name or id.
dap.target.Attach(attach_info, error);
}
-} else
+} else {
dap.target.LoadCore(core_file.data(), error);
-// Reenable async events
-dap.debugger.SetAsync(true);
+}
} else {
// We have "attachCommands" that are a set of commands that are expected
// to execute the commands after which a process should be created. If
there
diff --git a/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
index b7d3c8ced69f1..7a75cd93abc19 100644
--- a/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
@@ -10,6 +10,7 @@
#include "DAP.h"
#include "Handler/ResponseHandler.h"
#include "JSONUtils.h"
+#include "LLDBUtils.h"
#include "Protocol/ProtocolBase.h"
#include "Protocol/ProtocolRequests.h"
#include "RunInTerminal.h"
@@ -138,7 +139,7 @@ RunInTerminal(DAP &dap, const
protocol::LaunchRequestArguments &arguments) {
else
return pid.takeError();
- dap.debugger.SetAsync(false);
+ std::optional scope_sync_mode(dap.debugger);
lldb::SBError error;
dap.target.Attach(attach_info, error);
@@ -162,7 +163,7 @@ RunInTerminal(DAP &dap, const
protocol::LaunchRequestArguments &arguments) {
// Now that the actual target is just starting (i.e. exec was just invoked),
// we return the debugger to its async state.
- dap.debugger.SetAsync(true);
+ scope_sync_mode.reset();
// If sending the notification failed, the launcher should be dead by now and
// the async didAttach notification should have an error message, so we
@@ -244,9 +245,8 @@ llvm::Error BaseRequestHandler::LaunchProcess(
lldb::SBError error;
// Disable async events so the launch will be successful when we return
from
// the launch call and the launch will happen synchronously
-dap.debugger.SetAsync(false);
+ScopeSyncMode scope_sync_mode(dap.debugger);
dap.target.Launch(launch_info, error);
-dap.debugger.SetAsync(true);
if (error.Fail())
return llvm::make_error(error.GetCString());
} else {
diff --git a/lldb/tools/l
[Lldb-commits] [lldb] [lldb] Support alternatives for scope format entries (PR #137751)
https://github.com/JDevlieghere updated
https://github.com/llvm/llvm-project/pull/137751
>From b6618a2ecfe20880e323177f9683f51135b83fd6 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Mon, 28 Apr 2025 20:51:34 -0700
Subject: [PATCH 1/2] [lldb] Support alternatives for scope format entries
This PR implements support for specifying multiple alternatives for
scope format entries. Scopes are used to enclose things that should only
be printed when everything in the scope resolves.
For example, the following scope only resolves if both
`${line.file.basename}` and `${line.number}` resolve.
`
```
{ at ${line.file.basename}:${line.number}}
```
However, the current implementation doesn't let you specify what to
print when they don't resolve. This PR adds support for specifying
multiple alternative scopes, which are evaluated left-to-right.
For example:
```
{ at ${line.file.basename}:${line.number}| in ${function.name}| }
```
This will resolve to:
- ` at ${line.file.basename}:${line.number}` if the corresponding variables
resolve.
- Otherwise, this resolves to ` in ${function.name}` if `${function.name}`
resolves.
- Otherwise, this resolves to ` ` which always resolves.
This PR makes the `|` character a special character within a scope, but
allows it to be escaped.
I ended up with this approach because it fit quite nicely in the
existing architecture of the format entries and by limiting the
functionality to scopes, it sidesteps some complexity, like dealing with
recursion.
---
lldb/include/lldb/Core/FormatEntity.h| 27 +---
lldb/source/Core/FormatEntity.cpp| 87 +---
lldb/unittests/Core/FormatEntityTest.cpp | 59 ++--
3 files changed, 135 insertions(+), 38 deletions(-)
diff --git a/lldb/include/lldb/Core/FormatEntity.h
b/lldb/include/lldb/Core/FormatEntity.h
index 97065afe19bfe..6acf6fbe43239 100644
--- a/lldb/include/lldb/Core/FormatEntity.h
+++ b/lldb/include/lldb/Core/FormatEntity.h
@@ -11,10 +11,10 @@
#include "lldb/lldb-enumerations.h"
#include "lldb/lldb-types.h"
+#include "llvm/ADT/SmallVector.h"
#include
#include
#include
-
#include
#include
@@ -158,9 +158,7 @@ struct Entry {
}
Entry(Type t = Type::Invalid, const char *s = nullptr,
-const char *f = nullptr)
- : string(s ? s : ""), printf_format(f ? f : ""), type(t) {}
-
+const char *f = nullptr);
Entry(llvm::StringRef s);
Entry(char ch);
@@ -170,15 +168,19 @@ struct Entry {
void AppendText(const char *cstr);
- void AppendEntry(const Entry &&entry) { children.push_back(entry); }
+ void AppendEntry(const Entry &&entry);
+
+ void StartAlternative();
void Clear() {
string.clear();
printf_format.clear();
-children.clear();
+children_stack.clear();
+children_stack.emplace_back();
type = Type::Invalid;
fmt = lldb::eFormatDefault;
number = 0;
+level = 0;
deref = false;
}
@@ -191,7 +193,7 @@ struct Entry {
return false;
if (printf_format != rhs.printf_format)
return false;
-if (children != rhs.children)
+if (children_stack != rhs.children_stack)
return false;
if (type != rhs.type)
return false;
@@ -202,9 +204,18 @@ struct Entry {
return true;
}
+ std::vector &GetChildren();
+
std::string string;
std::string printf_format;
- std::vector children;
+
+ /// A stack of children entries, used by Scope entries to provide alterantive
+ /// children. All other entries have a stack of size 1.
+ /// @{
+ llvm::SmallVector, 1> children_stack;
+ size_t level = 0;
+ /// @}
+
Type type;
lldb::Format fmt = lldb::eFormatDefault;
lldb::addr_t number = 0;
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index 40e247a64b78c..031f0e57f132e 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -60,6 +60,7 @@
#include "llvm/Support/Regex.h"
#include "llvm/TargetParser/Triple.h"
+#include
#include
#include
#include
@@ -281,31 +282,53 @@ constexpr Definition g_top_level_entries[] = {
constexpr Definition g_root = Entry::DefinitionWithChildren(
"", EntryType::Root, g_top_level_entries);
+FormatEntity::Entry::Entry(Type t, const char *s, const char *f)
+: string(s ? s : ""), printf_format(f ? f : ""), children_stack({{}}),
+ type(t) {}
+
FormatEntity::Entry::Entry(llvm::StringRef s)
-: string(s.data(), s.size()), printf_format(), children(),
- type(Type::String) {}
+: string(s.data(), s.size()), children_stack({{}}), type(Type::String) {}
FormatEntity::Entry::Entry(char ch)
-: string(1, ch), printf_format(), children(), type(Type::String) {}
+: string(1, ch), printf_format(), children_stack({{}}), type(Type::String)
{
+}
+
+std::vector &FormatEntity::Entry::GetChildren() {
+ assert(level < children_stack.size());
+ return children_stack[level];
+}
void FormatEntity::Entry::AppendChar(char ch) {
-
[Lldb-commits] [lldb] [lldb-dap] Add an RAII helper for synchronous mode (NFC) (PR #137900)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/137900 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (PR #137904)
eronnen wrote: Added branch instructions asserts to the tests https://github.com/llvm/llvm-project/pull/137904 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [clang][modules] Lazily load by name lookups in module maps (PR #132853)
https://github.com/Bigcheese updated
https://github.com/llvm/llvm-project/pull/132853
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
}
.container { margin: 50px auto; max-width: 600px; text-align: center;
padding: 0 24px; }
a { color: #0366d6; text-decoration: none; }
a:hover { text-decoration: underline; }
h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px;
text-shadow: 0 1px 0 #fff; }
p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }
ul { list-style: none; margin: 25px 0; padding: 0; }
li { display: table-cell; font-weight: bold; width: 1%; }
.logo { display: inline-block; margin-top: 35px; }
.logo-img-2x { display: none; }
@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and ( min--moz-device-pixel-ratio: 2),
only screen and ( -o-min-device-pixel-ratio: 2/1),
only screen and (min-device-pixel-ratio: 2),
only screen and (min-resolution: 192dpi),
only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
}
#suggestions {
margin-top: 35px;
color: #ccc;
}
#suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
}
Whoa there!
You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang][modules] Lazily load by name lookups in module maps (PR #132853)
https://github.com/Bigcheese updated
https://github.com/llvm/llvm-project/pull/132853
>From cea7c581ff90952d112d912da02de688e09112f7 Mon Sep 17 00:00:00 2001
From: Michael Spencer
Date: Wed, 29 Jan 2025 12:49:29 -0800
Subject: [PATCH] [clang][modules] Lazily load by name lookups in module maps
Instead of eagerly populating the `clang::ModuleMap` when looking up
a module by name, this patch changes `HeaderSearch` to only load the
modules that are actually used.
This introduces `ModuleMap::findOrLoadModule` which will load modules
from parsed but not loaded module maps. This cannot be used anywhere
that the module loading code calls into as it can create infinite
recursion.
This currently just reparses module maps when looking up a module by
header. This is fine as redeclarations are allowed from the same file,
but future patches will also make looking up a module by header lazy.
This patch changes the shadow.m test to use explicitly built modules
and `#import`. This test and the shadow feature are very brittle and
do not work in general. The test relied on pcm files being left behind
by prior failing clang invocations that were then reused by the last
invocation. If you clean the cache then the last invocation will
always fail. This is because the input module map and the
`-fmodule-map-file=` module map are parsed in the same module scope,
and `-fmodule-map-file=` is forwarded to implicit module builds. That
means you are guaranteed to hit a module redeclaration error if the TU
actually imports the module it is trying to shadow.
This patch changes when we load A2's module map to after the `A`
module has been loaded, which sets the `IsFromModuleFile` bit on `A`.
This means that A2's `A` is skipped entirely instead of creating a
shadow module, and we get textual inclusion. It is possible to
construct a case where this would happen before this patch too.
An upcoming patch in this series will rework shadowing to work in the
general case, but that's only possible once header -> module lookup is
lazy too.
---
.../modularize/ModularizeUtilities.cpp| 2 +-
clang/include/clang/Basic/DiagnosticGroups.td | 1 +
.../include/clang/Basic/DiagnosticLexKinds.td | 6 +
clang/include/clang/Lex/HeaderSearch.h| 70 --
clang/include/clang/Lex/ModuleMap.h | 29 ++-
clang/include/clang/Lex/ModuleMapFile.h | 9 +
clang/lib/Frontend/CompilerInstance.cpp | 4 +-
clang/lib/Frontend/FrontendAction.cpp | 8 +-
clang/lib/Lex/HeaderSearch.cpp| 234 --
clang/lib/Lex/ModuleMap.cpp | 162 ++--
clang/lib/Lex/ModuleMapFile.cpp | 3 +
clang/lib/Sema/SemaModule.cpp | 2 +-
.../modules-canononical-module-map-case.c | 11 +
clang/test/Modules/Inputs/shadow/A1/A1.h | 0
.../Modules/Inputs/shadow/A1/module.modulemap | 4 +-
clang/test/Modules/Inputs/shadow/A2/A2.h | 0
.../Modules/Inputs/shadow/A2/module.modulemap | 4 +-
clang/test/Modules/lazy-by-name-lookup.c | 31 +++
clang/test/Modules/shadow.m | 11 +-
.../Clang/ClangModulesDeclVendor.cpp | 2 +-
20 files changed, 457 insertions(+), 136 deletions(-)
create mode 100644 clang/test/Modules/Inputs/shadow/A1/A1.h
create mode 100644 clang/test/Modules/Inputs/shadow/A2/A2.h
create mode 100644 clang/test/Modules/lazy-by-name-lookup.c
diff --git a/clang-tools-extra/modularize/ModularizeUtilities.cpp
b/clang-tools-extra/modularize/ModularizeUtilities.cpp
index ef57b0f5bbea5..576e863c8a9d2 100644
--- a/clang-tools-extra/modularize/ModularizeUtilities.cpp
+++ b/clang-tools-extra/modularize/ModularizeUtilities.cpp
@@ -290,7 +290,7 @@ std::error_code ModularizeUtilities::loadModuleMap(
Target.get(), *HeaderInfo));
// Parse module.modulemap file into module map.
- if (ModMap->loadModuleMapFile(ModuleMapEntry, false, Dir)) {
+ if (ModMap->parseAndLoadModuleMapFile(ModuleMapEntry, false, Dir)) {
return std::error_code(1, std::generic_category());
}
diff --git a/clang/include/clang/Basic/DiagnosticGroups.td
b/clang/include/clang/Basic/DiagnosticGroups.td
index 75e8fc541305b..273d6d004f0db 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -606,6 +606,7 @@ def ModuleImport : DiagGroup<"module-import">;
def ModuleConflict : DiagGroup<"module-conflict">;
def ModuleFileExtension : DiagGroup<"module-file-extension">;
def ModuleIncludeDirectiveTranslation :
DiagGroup<"module-include-translation">;
+def ModuleMap : DiagGroup<"module-map">;
def RoundTripCC1Args : DiagGroup<"round-trip-cc1-args">;
def NewlineEOF : DiagGroup<"newline-eof">;
def Nullability : DiagGroup<"nullability">;
diff --git a/clang/include/clang/Basic/DiagnosticLexKinds.td
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index f29edfa835d42..503c68eaacf7e 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/in
