[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)
@@ -111,7 +111,42 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_expression
+//postfix_expression "[" integer_literal "]"
+//
+ASTNodeUP DILParser::ParsePostfixExpression() {
+ ASTNodeUP lhs = ParsePrimaryExpression();
+ while (CurToken().Is(Token::l_square)) {
+uint32_t loc = CurToken().GetLocation();
+Token token = CurToken();
+switch (token.GetKind()) {
+case Token::l_square: {
+ m_dil_lexer.Advance();
+ auto rhs = ParseIntegerConstant();
labath wrote:
LLVM generally has a very cautious stance towards auto:
https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
In this case, the type of rhs is not obvious from the immediate, and for the
correctness of the code, it is important to know whether the function returns
`int`, `optional`, `Expected` or something else.
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/138551 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix race condition during iteration through modules (#139283) (PR #139862)
nd wrote: Sorry, I haven't read the LLVM GitHub user guide before submitting the PR and didn't realize that force pushes are to be avoided. Please let me know if I need to rework the request somehow. https://github.com/llvm/llvm-project/pull/139862 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added 32-bit XCOFF Executable support (PR #139875)
https://github.com/labath approved this pull request. Looks fine. Ship it. https://github.com/llvm/llvm-project/pull/139875 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added 32-bit XCOFF Executable support (PR #139875)
@@ -97,14 +97,26 @@ class ObjectFileXCOFF : public lldb_private::ObjectFile {
lldb::DataBufferSP header_data_sp,
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
+ struct XCOFF32 {
+using SectionHeader = llvm::object::XCOFFSectionHeader32;
+static constexpr bool Is64Bit = false;
+ };
+ struct XCOFF64 {
+using SectionHeader = llvm::object::XCOFFSectionHeader64;
+static constexpr bool Is64Bit = true;
+ };
+
+ template
+ void
+ CreateSectionsWithBitness(lldb_private::SectionList &unified_section_list);
+
labath wrote:
Could this be `private:` ?
https://github.com/llvm/llvm-project/pull/139875
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added 32-bit XCOFF Executable support (PR #139875)
@@ -191,20 +193,36 @@ void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
bool ObjectFileXCOFF::IsStripped() { return false; }
void ObjectFileXCOFF::CreateSections(SectionList &unified_section_list) {
+
if (m_sections_up)
return;
m_sections_up = std::make_unique();
- ModuleSP module_sp(GetModule());
+ if (m_binary->is64Bit())
+CreateSectionsWithBitness(unified_section_list);
+ else
+CreateSectionsWithBitness(unified_section_list);
+}
+template auto GetSections(llvm::object::XCOFFObjectFile *binary) {
labath wrote:
```suggestion
template static auto GetSections(llvm::object::XCOFFObjectFile
*binary) {
```
https://github.com/llvm/llvm-project/pull/139875
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added 32-bit XCOFF Executable support (PR #139875)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/139875 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Call Target::ClearAllLoadedSections even earlier (PR #140228)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
This reapplies https://github.com/llvm/llvm-project/pull/138892, which was
reverted in
https://github.com/llvm/llvm-project/commit/5fb9dca14aeaf12219ff149bf3a4f94c8dc58d8b
due to failures on windows.
Windows loads modules from the Process class, and it does that quite
early, and it kinda makes sense which is why I'm moving the clearing
code even earlier.
The original commit message was:
Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).
This used to work until https://github.com/llvm/llvm-project/pull/109477, which
enabled the dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.
Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.
This fixes TestDynamicValue.py:test_from_core_file on darwin.
---
Full diff: https://github.com/llvm/llvm-project/pull/140228.diff
3 Files Affected:
- (modified)
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp (-1)
- (modified) lldb/source/Target/Process.cpp (+3)
- (modified) lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py (-1)
``diff
diff --git
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index 578ab12268ea3..1270d57423c7b 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -872,7 +872,6 @@ void DynamicLoaderDarwin::PrivateInitialize(Process
*process) {
StateAsCString(m_process->GetState()));
Clear(true);
m_process = process;
- m_process->GetTarget().ClearAllLoadedSections();
}
// Member function that gets called when the process state changes.
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 13ff12b4ff953..c377feec86c16 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -2675,6 +2675,7 @@ Status Process::LaunchPrivate(ProcessLaunchInfo
&launch_info, StateType &state,
m_jit_loaders_up.reset();
m_system_runtime_up.reset();
m_os_up.reset();
+ GetTarget().ClearAllLoadedSections();
{
std::lock_guard guard(m_process_input_reader_mutex);
@@ -2799,6 +2800,7 @@ Status Process::LaunchPrivate(ProcessLaunchInfo
&launch_info, StateType &state,
}
Status Process::LoadCore() {
+ GetTarget().ClearAllLoadedSections();
Status error = DoLoadCore();
if (error.Success()) {
ListenerSP listener_sp(
@@ -2984,6 +2986,7 @@ Status Process::Attach(ProcessAttachInfo &attach_info) {
m_jit_loaders_up.reset();
m_system_runtime_up.reset();
m_os_up.reset();
+ GetTarget().ClearAllLoadedSections();
lldb::pid_t attach_pid = attach_info.GetProcessID();
Status error;
diff --git a/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
b/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
index cd95a9ff3fe8c..faa35421ff60b 100644
--- a/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
+++ b/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
@@ -282,7 +282,6 @@ def test_from_forward_decl(self):
@no_debug_info_test
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24663")
-@expectedFailureDarwin # dynamic loader unloads modules
@expectedFailureAll(archs=["arm"]) # Minidump saving not implemented
def test_from_core_file(self):
"""Test fetching C++ dynamic values from core files. Specifically, test
``
https://github.com/llvm/llvm-project/pull/140228
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][lldb-dap] Basic implementation of a deferred request. (PR #140260)
https://github.com/da-viper updated
https://github.com/llvm/llvm-project/pull/140260
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][lldb-dap] Basic implementation of a deferred request. (PR #140260)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Ebuka Ezike (da-viper)
Changes
Fixes #140154
Basic implementation of defering requests.
It no longer depends on a white list of request, So if there is any future
breakpoint types added to the DAP specification. it will not break existing
binary.
It can further be extended to defer depending of the request arguments.
---
Full diff: https://github.com/llvm/llvm-project/pull/140260.diff
6 Files Affected:
- (modified) lldb/tools/lldb-dap/DAP.cpp (+8-11)
- (modified) lldb/tools/lldb-dap/DAP.h (+1-1)
- (modified) lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp (+4)
- (modified) lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp (+4)
- (modified) lldb/tools/lldb-dap/Handler/RequestHandler.cpp (+6-2)
- (modified) lldb/tools/lldb-dap/Handler/RequestHandler.h (+7-1)
``diff
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 56a0c38b00037..a1f738eef5fcc 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -726,7 +726,7 @@ void DAP::SetTarget(const lldb::SBTarget target) {
}
}
-bool DAP::HandleObject(const Message &M) {
+bool DAP::HandleObject(const Message &M, bool &defer) {
TelemetryDispatcher dispatcher(&debugger);
dispatcher.Set("client_name", transport.GetClientName().str());
if (const auto *req = std::get_if(&M)) {
@@ -748,7 +748,7 @@ bool DAP::HandleObject(const Message &M) {
dispatcher.Set("client_data",
llvm::Twine("request_command:", req->command).str());
if (handler_pos != request_handlers.end()) {
- handler_pos->second->Run(*req);
+ defer = handler_pos->second->Run(*req);
return true; // Success
}
@@ -918,17 +918,11 @@ llvm::Error DAP::Loop() {
// The launch sequence is special and we need to carefully handle
// packets in the right order. Until we've handled configurationDone,
- bool add_to_pending_queue = false;
-
if (const protocol::Request *req =
std::get_if(&*next)) {
llvm::StringRef command = req->command;
if (command == "disconnect")
disconnecting = true;
-if (!configuration_done)
- add_to_pending_queue =
- command != "initialize" && command != "configurationDone" &&
- command != "disconnect" && !command.ends_with("Breakpoints");
}
const std::optional cancel_args =
@@ -956,8 +950,7 @@ llvm::Error DAP::Loop() {
{
std::lock_guard guard(m_queue_mutex);
-auto &queue = add_to_pending_queue ? m_pending_queue : m_queue;
-queue.push_back(std::move(*next));
+m_queue.push_back(std::move(*next));
}
m_queue_cv.notify_one();
}
@@ -984,9 +977,13 @@ llvm::Error DAP::Loop() {
// Unlock while we're processing the event.
lock.unlock();
-if (!HandleObject(next))
+bool defer_message = false;
+if (!HandleObject(next, defer_message))
return llvm::createStringError(llvm::inconvertibleErrorCode(),
"unhandled packet");
+if (defer_message) {
+ m_pending_queue.push_back(next);
+}
}
return ToError(queue_reader.get());
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index c1a1130b1e59f..a77a1561c5db2 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -339,7 +339,7 @@ struct DAP {
/// listeing for its breakpoint events.
void SetTarget(const lldb::SBTarget target);
- bool HandleObject(const protocol::Message &M);
+ bool HandleObject(const protocol::Message &M, bool &defer);
/// Disconnect the DAP session.
llvm::Error Disconnect();
diff --git a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
index 0293ffbd0c922..96fb7682f240a 100644
--- a/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
@@ -160,4 +160,8 @@ void AttachRequestHandler::PostRun() const {
dap.target.GetProcess().Continue();
}
+bool AttachRequestHandler::DeferRequest() const {
+ return !dap.configuration_done;
+}
+
} // namespace lldb_dap
diff --git a/lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp
index 22d1a090187d8..e4163827ac69c 100644
--- a/lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp
@@ -88,4 +88,8 @@ void LaunchRequestHandler::PostRun() const {
dap.target.GetProcess().Continue();
}
+bool LaunchRequestHandler::DeferRequest() const {
+ return !dap.configuration_done;
+}
+
} // namespace lldb_dap
diff --git a/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
index 93bc80a38e29d..074a76c928240 100644
--- a/lldb/tools/lldb-d
[Lldb-commits] [lldb] [lldb][AArch64] Fix Apple M4 on Linux (PR #135563)
DavidSpickett wrote: I think there are kernel issues that need to be fixed before all the LLDB features can work. So don't waste your own time on this right now, I will coordinate with Arm's kernel team to get this working. https://github.com/llvm/llvm-project/pull/135563 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Retcon SBValue::GetChildAtIndex(synthetic=true) (PR #140065)
@@ -193,7 +188,7 @@ class LLDB_API SBValue {
/// and also if the target can be run to figure out the dynamic
/// type of the child value.
///
- /// \param[in] can_create_synthetic
+ /// \param[in] use_synthetic
labath wrote:
Sounds good. I wasn't too happy with the name myself.
https://github.com/llvm/llvm-project/pull/140065
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Retcon SBValue::GetChildAtIndex(synthetic=true) (PR #140065)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/140065
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] Call Target::ClearAllLoadedSections even earlier (PR #140228)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/140228
This reapplies https://github.com/llvm/llvm-project/pull/138892, which was
reverted in
https://github.com/llvm/llvm-project/commit/5fb9dca14aeaf12219ff149bf3a4f94c8dc58d8b
due to failures on windows.
Windows loads modules from the Process class, and it does that quite
early, and it kinda makes sense which is why I'm moving the clearing
code even earlier.
The original commit message was:
Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).
This used to work until https://github.com/llvm/llvm-project/pull/109477, which
enabled the dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.
Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.
This fixes TestDynamicValue.py:test_from_core_file on darwin.
>From 438daf635e8d57cdd9cf854c505ec9a434d11358 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Wed, 14 May 2025 11:16:55 +0200
Subject: [PATCH 1/2] [lldb] Call Target::ClearAllLoadedSections earlier
(#138892)
Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).
This used to work until #109477, which enabled the dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.
Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.
This fixes TestDynamicValue.py:test_from_core_file on darwin.
---
.../Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp | 1 -
lldb/source/Target/Process.cpp| 4
lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py | 1 -
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index 578ab12268ea3..1270d57423c7b 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -872,7 +872,6 @@ void DynamicLoaderDarwin::PrivateInitialize(Process
*process) {
StateAsCString(m_process->GetState()));
Clear(true);
m_process = process;
- m_process->GetTarget().ClearAllLoadedSections();
}
// Member function that gets called when the process state changes.
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 13ff12b4ff953..7c5512598bbb6 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -2763,6 +2763,7 @@ Status Process::LaunchPrivate(ProcessLaunchInfo
&launch_info, StateType &state,
}
if (state == eStateStopped || state == eStateCrashed) {
+GetTarget().ClearAllLoadedSections();
DidLaunch();
// Now that we know the process type, update its signal responses from the
@@ -2799,6 +2800,7 @@ Status Process::LaunchPrivate(ProcessLaunchInfo
&launch_info, StateType &state,
}
Status Process::LoadCore() {
+ GetTarget().ClearAllLoadedSections();
Status error = DoLoadCore();
if (error.Success()) {
ListenerSP listener_sp(
@@ -3094,6 +3096,8 @@ void Process::CompleteAttach() {
Log *log(GetLog(LLDBLog::Process | LLDBLog::Target));
LLDB_LOGF(log, "Process::%s()", __FUNCTION__);
+ GetTarget().ClearAllLoadedSections();
+
// Let the process subclass figure out at much as it can about the process
// before we go looking for a dynamic loader plug-in.
ArchSpec process_arch;
diff --git a/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
b/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
index cd95a9ff3fe8c..faa35421ff60b 100644
--- a/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
+++ b/lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py
@@ -282,7 +282,6 @@ def test_from_forward_decl(self):
@no_debug_info_test
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24663")
-@expectedFailureDarwin # dynamic loader unloads modules
@expectedFailureAll(archs=["arm"]) # Minidump saving not implemented
def test_from_core_file(self):
"""Test fetching C++ dynamic values from core files. Specifica
[Lldb-commits] [lldb] [lldb][DataFormatters] Adjust retrieval of unordered_map element type (PR #140256)
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/140256
A user ran into an issue where the libc++ std::unordered_map` formatter fails
because it can't deduce the `element_type`. That happens because the
`node_type` is a forwad declaration. And, in fact, dsymutil stripped the
definition for `std::__1::__hash_node<...>` for a particular instantiation.
While I'm still unclear whether this is a dsymutil bug, this patch works around
said issue by getting the element type from the `__table_` member.
Drive-by:
- Set the `m_element_type` in `Update`, which is where the other members are
initialized
I don't have a reduced example of this unfortunately. But the crux of the issue
is that `std::__1::__hash_node<...>` only has a forward declaration in the
dsym. Then trying to call `GetTypeTemplateArgument` on that `CompilerType`
fails. And even if the definition was present in the dsym it seems like we're
stopped in a context where the CU only had a forward declaration DIE for that
type and the `node_type` never ends up being completed with the definition that
lives in another CU.
rdar://150813798
>From f1b931c5b80abb623ff98ef5e55aa662765de50e Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 16 May 2025 11:17:32 +0100
Subject: [PATCH] [lldb][DataFormatters] Adjust retrieval of unordered_map
element type
A user ran into an issue where the libc++ std::unordered_map` formatter
fails because it can't deduce the `element_type`. That happens because
the `node_type` is a forwad declaration. And, in fact, dsymutil stripped
the definition for `std::__1::__hash_node<...>` for a particular
instantiation. While I'm still unclear whether this is a dsymutil bug,
this patch works around said issue by getting the element type from the
`__table_` member.
Drive-by:
- Set the `m_element_type` in `Update`, which is where the other members
are initialized
I don't have a reduced example of this unfortunately. But the crux of
the issue is that `std::__1::__hash_node<...>` only has a forward
declaration in the dsym. Then trying to call `GetTypeTemplateArgument`
on that `CompilerType` fails. And even if the definition was present in
the dsym it seems like we're stopped in a context where the CU only had
a forward declaration DIE for that type and the `node_type` never ends
up being completed with the definition that lives in another CU.
rdar://150813798
---
.../Language/CPlusPlus/LibCxxUnorderedMap.cpp | 23 ++-
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
b/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
index aad387137ea50..642723dd91132 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
@@ -44,7 +44,7 @@ class LibcxxStdUnorderedMapSyntheticFrontEnd
private:
CompilerType GetNodeType();
- CompilerType GetElementType(CompilerType node_type);
+ CompilerType GetElementType(CompilerType table_type);
llvm::Expected CalculateNumChildrenImpl(ValueObject &table);
CompilerType m_element_type;
@@ -98,8 +98,8 @@ static bool isUnorderedMap(ConstString type_name) {
}
CompilerType lldb_private::formatters::LibcxxStdUnorderedMapSyntheticFrontEnd::
-GetElementType(CompilerType node_type) {
- CompilerType element_type = node_type.GetTypeTemplateArgument(0);
+GetElementType(CompilerType table_type) {
+ auto element_type = table_type.GetTypedefedType().GetTypeTemplateArgument(0);
// This synthetic provider is used for both unordered_(multi)map and
// unordered_(multi)set. For unordered_map, the element type has an
@@ -114,7 +114,7 @@ CompilerType
lldb_private::formatters::LibcxxStdUnorderedMapSyntheticFrontEnd::
element_type.GetFieldAtIndex(0, name, nullptr, nullptr, nullptr);
CompilerType actual_type = field_type.GetTypedefedType();
if (isStdTemplate(actual_type.GetTypeName(), "pair"))
- element_type = actual_type;
+ return actual_type;
}
return element_type;
@@ -161,13 +161,6 @@ lldb::ValueObjectSP lldb_private::formatters::
ValueObjectSP value_sp = node_sp->GetChildMemberWithName("__value_");
ValueObjectSP hash_sp = node_sp->GetChildMemberWithName("__hash_");
if (!hash_sp || !value_sp) {
- if (!m_element_type) {
-m_node_type = GetNodeType();
-if (!m_node_type)
- return nullptr;
-
-m_element_type = GetElementType(m_node_type);
- }
node_sp = m_next_element->Cast(m_node_type.GetPointerType())
->Dereference(error);
if (!node_sp || error.Fail())
@@ -271,6 +264,14 @@
lldb_private::formatters::LibcxxStdUnorderedMapSyntheticFrontEnd::Update() {
if (!table_sp)
return lldb::ChildCacheState::eRefetch;
+ m_node_type = GetNodeType();
+ if (!m_node_type)
+return lldb::ChildCacheState::eRefetch;
+
+ m_element_type = GetElementType(
[Lldb-commits] [lldb] [lldb][DataFormatters] Adjust retrieval of unordered_map element type (PR #140256)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Michael Buch (Michael137)
Changes
A user ran into an issue where the libc++ std::unordered_map` formatter fails
because it can't deduce the `element_type`. That happens because the
`node_type` is a forwad declaration. And, in fact, dsymutil stripped the
definition for `std::__1::__hash_node<...>` for a particular
instantiation. While I'm still unclear whether this is a dsymutil bug, this
patch works around said issue by getting the element type from the `__table_`
member.
Drive-by:
- Set the `m_element_type` in `Update`, which is where the other members are
initialized
I don't have a reduced example of this unfortunately. But the crux of the issue
is that `std::__1::__hash_node<...>` only has a forward declaration in
the dsym. Then trying to call `GetTypeTemplateArgument` on that `CompilerType`
fails. And even if the definition was present in the dsym it seems like we're
stopped in a context where the CU only had a forward declaration DIE for that
type and the `node_type` never ends up being completed with the definition that
lives in another CU.
rdar://150813798
---
Full diff: https://github.com/llvm/llvm-project/pull/140256.diff
1 Files Affected:
- (modified) lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
(+12-11)
``diff
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
b/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
index aad387137ea50..642723dd91132 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
@@ -44,7 +44,7 @@ class LibcxxStdUnorderedMapSyntheticFrontEnd
private:
CompilerType GetNodeType();
- CompilerType GetElementType(CompilerType node_type);
+ CompilerType GetElementType(CompilerType table_type);
llvm::Expected CalculateNumChildrenImpl(ValueObject &table);
CompilerType m_element_type;
@@ -98,8 +98,8 @@ static bool isUnorderedMap(ConstString type_name) {
}
CompilerType lldb_private::formatters::LibcxxStdUnorderedMapSyntheticFrontEnd::
-GetElementType(CompilerType node_type) {
- CompilerType element_type = node_type.GetTypeTemplateArgument(0);
+GetElementType(CompilerType table_type) {
+ auto element_type = table_type.GetTypedefedType().GetTypeTemplateArgument(0);
// This synthetic provider is used for both unordered_(multi)map and
// unordered_(multi)set. For unordered_map, the element type has an
@@ -114,7 +114,7 @@ CompilerType
lldb_private::formatters::LibcxxStdUnorderedMapSyntheticFrontEnd::
element_type.GetFieldAtIndex(0, name, nullptr, nullptr, nullptr);
CompilerType actual_type = field_type.GetTypedefedType();
if (isStdTemplate(actual_type.GetTypeName(), "pair"))
- element_type = actual_type;
+ return actual_type;
}
return element_type;
@@ -161,13 +161,6 @@ lldb::ValueObjectSP lldb_private::formatters::
ValueObjectSP value_sp = node_sp->GetChildMemberWithName("__value_");
ValueObjectSP hash_sp = node_sp->GetChildMemberWithName("__hash_");
if (!hash_sp || !value_sp) {
- if (!m_element_type) {
-m_node_type = GetNodeType();
-if (!m_node_type)
- return nullptr;
-
-m_element_type = GetElementType(m_node_type);
- }
node_sp = m_next_element->Cast(m_node_type.GetPointerType())
->Dereference(error);
if (!node_sp || error.Fail())
@@ -271,6 +264,14 @@
lldb_private::formatters::LibcxxStdUnorderedMapSyntheticFrontEnd::Update() {
if (!table_sp)
return lldb::ChildCacheState::eRefetch;
+ m_node_type = GetNodeType();
+ if (!m_node_type)
+return lldb::ChildCacheState::eRefetch;
+
+ m_element_type = GetElementType(table_sp->GetCompilerType());
+ if (!m_element_type)
+return lldb::ChildCacheState::eRefetch;
+
ValueObjectSP tree_sp = GetTreePointer(*table_sp);
if (!tree_sp)
return lldb::ChildCacheState::eRefetch;
``
https://github.com/llvm/llvm-project/pull/140256
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][lldb-dap] Basic implementation of a deferred request. (PR #140260)
@@ -748,7 +748,7 @@ bool DAP::HandleObject(const Message &M) {
dispatcher.Set("client_data",
llvm::Twine("request_command:", req->command).str());
if (handler_pos != request_handlers.end()) {
- handler_pos->second->Run(*req);
+ defer = handler_pos->second->Run(*req);
ashgti wrote:
Should we check the deferred call here like?
```cpp
if (handler_pos->second->DeferRequest())
m_pending_queue.push_back(M);
else
handler_pos->second->Run(*req);
```
https://github.com/llvm/llvm-project/pull/140260
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][lldb-dap] Basic implementation of a deferred request. (PR #140260)
@@ -46,7 +46,14 @@ class BaseRequestHandler {
virtual ~BaseRequestHandler() = default;
- void Run(const protocol::Request &);
+ /// Return `true` if the request should be deferred.
+ [[nodiscard]]
+ bool Run(const protocol::Request &);
+
+ [[nodiscard]]
+ virtual bool DeferRequest() const {
ashgti wrote:
This is specifically about deferring until configurationDone is called. We
don't really have support for an async request handler yet. I thought about
implementing an `AsyncRequestHandler` that would allow the request handler to
unblock the handler queue before sending a reply, but I haven't needed it just
yet so I haven't sent that out for a PR.
Thats a long winded way of saying, should we make this more specific? Maybe
`DeferUntilConfigurationDone`? I'm open to other names, just want to be clear.
https://github.com/llvm/llvm-project/pull/140260
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adding additional asserts to unit tests. (PR #140107)
@@ -60,7 +60,7 @@ def test_breakpoint_events(self): response = self.dap_server.request_setBreakpoints( main_source_path, [main_bp_line] ) -self.assertTrue(response) +self.assertTrue(response["success"]) ashgti wrote: I can send a follow up for that. https://github.com/llvm/llvm-project/pull/140107 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 087a5d2 - [lldb-dap] Adding additional asserts to unit tests. (#140107)
Author: John Harrison
Date: 2025-05-16T08:47:01-07:00
New Revision: 087a5d2ec7897cd99d3787820711fec76a8e1792
URL:
https://github.com/llvm/llvm-project/commit/087a5d2ec7897cd99d3787820711fec76a8e1792
DIFF:
https://github.com/llvm/llvm-project/commit/087a5d2ec7897cd99d3787820711fec76a8e1792.diff
LOG: [lldb-dap] Adding additional asserts to unit tests. (#140107)
Adding an assert that the 'continue' request succeeds caused a number of
tests to fail. This showed a number of tests that were not specifying if
they should be stopped or not at key points in the test. This is likely
contributing to these tests being flaky since the debugger is not in the
expected state.
Additionally, I spent a little time trying to improve the readability of
the dap_server.py and lldbdap_testcase.py.
Added:
Modified:
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
lldb/test/API/tools/lldb-dap/breakpoint-events/TestDAP_breakpointEvents.py
lldb/test/API/tools/lldb-dap/cancel/TestDAP_cancel.py
lldb/test/API/tools/lldb-dap/commands/TestDAP_commands.py
lldb/test/API/tools/lldb-dap/completions/TestDAP_completions.py
lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
lldb/test/API/tools/lldb-dap/coreFile/TestDAP_coreFile.py
lldb/test/API/tools/lldb-dap/exception/TestDAP_exception.py
lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
lldb/test/API/tools/lldb-dap/module/TestDAP_module.py
lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
lldb/test/API/tools/lldb-dap/restart/TestDAP_restart.py
lldb/test/API/tools/lldb-dap/stop-hooks/TestDAP_stop_hooks.py
lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
lldb/tools/lldb-dap/DAPError.cpp
lldb/tools/lldb-dap/DAPError.h
lldb/tools/lldb-dap/Handler/ContinueRequestHandler.cpp
lldb/tools/lldb-dap/Handler/RequestHandler.h
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 73f7b0e91d57a..d3589e78b6bc7 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -12,6 +12,13 @@
import sys
import threading
import time
+from typing import Any, Optional, Union, BinaryIO, TextIO
+
+## DAP type references
+Event = dict[str, Any]
+Request = dict[str, Any]
+Response = dict[str, Any]
+ProtocolMessage = Union[Event, Request, Response]
def dump_memory(base_addr, data, num_per_line, outfile):
@@ -98,55 +105,40 @@ def dump_dap_log(log_file):
print("= END =", file=sys.stderr)
-def read_packet_thread(vs_comm, log_file):
-done = False
-try:
-while not done:
-packet = read_packet(vs_comm.recv, trace_file=vs_comm.trace_file)
-# `packet` will be `None` on EOF. We want to pass it down to
-# handle_recv_packet anyway so the main thread can handle
unexpected
-# termination of lldb-dap and stop waiting for new packets.
-done = not vs_comm.handle_recv_packet(packet)
-finally:
-# Wait for the process to fully exit before dumping the log file to
-# ensure we have the entire log contents.
-if vs_comm.process is not None:
-try:
-# Do not wait forever, some logs are better than none.
-vs_comm.process.wait(timeout=20)
-except subprocess.TimeoutExpired:
-pass
-dump_dap_log(log_file)
-
-
class DebugCommunication(object):
-def __init__(self, recv, send, init_commands, log_file=None):
-self.trace_file = None
+def __init__(
+self,
+recv: BinaryIO,
+send: BinaryIO,
+init_commands: list[str],
+log_file: Optional[TextIO] = None,
+):
+# For debugging test failures, try setting `trace_file = sys.stderr`.
+self.trace_file: Optional[TextIO] = None
+self.log_file = log_file
self.send = send
self.recv = recv
-self.recv_packets = []
+self.recv_packets: list[Optional[ProtocolMessage]] = []
self.recv_condition = threading.Condition()
-self.recv_thread = threading.Thread(
-target=read_packet_thread, args=(self, log_file)
-)
+self.recv_thread = threading.Thread(target=self._read_packet_thread)
self.process_event_body = None
-self.exit_status = None
+self.exit_status: Optional[int] = None
self.initialize_body = None
-self.thread_stop_reasons = {}
-self.progress_events = []
+self.progress_events: list[Event] = []
self.reverse_requests = []
self.sequence = 1
[Lldb-commits] [lldb] [lldb-dap] Adding additional asserts to unit tests. (PR #140107)
https://github.com/ashgti closed https://github.com/llvm/llvm-project/pull/140107 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][lldb-dap] Basic implementation of a deferred request. (PR #140260)
https://github.com/JDevlieghere commented: I like the idea of making the request handlers responsible for telling us whether they should be deferred compared to the allow-list I implemented. That's definitely an improvement. What I don't like is how this introduces more statefulness, especially in the request handlers. The queueing/deferring logic isn't trivial and I would strongly prefer if we could keep it centralized as much as possible. With this PR we end up with both a separate queue and a method that makes the `Run` operation behaves differently depending on the global DAP state (i.e. if we've send the configuration request). Would it be possible to have the RequestHandlers advertise whether or not they should be deferred until the configuration is done (e.g. `DeferredUntilConfigurationDone`), and keep the latter an implementation detail of the DAP class? And strictly handle deferring at the queue level? PS: Small nit, but your PR is titled "Basic implementation of a deferred request." which isn't accurate because deferred requests are already implemented. A better title would be "Change the way we defer requests" or something similar. https://github.com/llvm/llvm-project/pull/140260 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix race condition during iteration through modules (#139283) (PR #139862)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/139862 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)
@@ -111,7 +111,42 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_expression
+//postfix_expression "[" integer_literal "]"
+//
+ASTNodeUP DILParser::ParsePostfixExpression() {
+ ASTNodeUP lhs = ParsePrimaryExpression();
+ while (CurToken().Is(Token::l_square)) {
+uint32_t loc = CurToken().GetLocation();
+Token token = CurToken();
+switch (token.GetKind()) {
+case Token::l_square: {
+ m_dil_lexer.Advance();
+ auto rhs = ParseIntegerConstant();
kuilpd wrote:
I see, thank you!
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix race condition during iteration through modules (#139283) (PR #139862)
github-actions[bot] wrote: @nd Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with a build, you may receive a report in an email or a comment on this PR. Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues. How to do this, and the rest of the post-merge process, is covered in detail [here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr). If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of [LLVM development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy). You can fix your changes and open a new PR to merge them again. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! https://github.com/llvm/llvm-project/pull/139862 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c72c0b2 - Fix race condition during iteration through modules (#139283) (#139862)
Author: nd
Date: 2025-05-16T09:09:50-07:00
New Revision: c72c0b298c13ebc4d374e84b8ea20f8ca4f5ace2
URL:
https://github.com/llvm/llvm-project/commit/c72c0b298c13ebc4d374e84b8ea20f8ca4f5ace2
DIFF:
https://github.com/llvm/llvm-project/commit/c72c0b298c13ebc4d374e84b8ea20f8ca4f5ace2.diff
LOG: Fix race condition during iteration through modules (#139283) (#139862)
Use the locking iterator to ensure module don't change during iteration.
Added:
Modified:
lldb/source/Target/Target.cpp
Removed:
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 7f61f8689fb95..9660fc97970b0 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -1511,8 +1511,7 @@ bool Target::IgnoreWatchpointByID(lldb::watch_id_t
watch_id,
ModuleSP Target::GetExecutableModule() {
// search for the first executable in the module list
- for (size_t i = 0; i < m_images.GetSize(); ++i) {
-ModuleSP module_sp = m_images.GetModuleAtIndex(i);
+ for (ModuleSP module_sp : m_images.Modules()) {
lldb_private::ObjectFile *obj = module_sp->GetObjectFile();
if (obj == nullptr)
continue;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
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] Add array subscription and integer parsing to DIL (PR #138551)
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs_or_err) {
+return lhs_or_err;
+ }
+ lldb::ValueObjectSP base = *lhs_or_err;
+ const llvm::APInt *index = node->GetIndex();
+
+ Status error;
+ if (base->GetCompilerType().IsReferenceType()) {
+base = base->Dereference(error);
+if (error.Fail())
+ return error.ToError();
+ }
+
+ // Check to see if 'base' has a synthetic value; if so, try using that.
+ uint64_t child_idx = index->getZExtValue();
+ if (base->HasSyntheticValue()) {
+lldb::ValueObjectSP synthetic = base->GetSyntheticValue();
+if (synthetic && synthetic != base) {
+ uint32_t num_children = synthetic->GetNumChildrenIgnoringErrors();
kuilpd wrote:
> Is it possible that some (simple) data formatter implements GetChildAtIndex
> as return foo without checking whether the index argument is in range?
One thing I can add that I noticed: that code worked when I tried it from
console lldb, but didn't work on the same executable and input string when
called from Python tests. I'm not sure why.
I changed the call to `GetNumChildren`, I think I'd prefer a vector telling me
that I'm out of bounds instead of returning 0 like it's a correct value from
the vector.
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Extending LLDB to work on AIX (PR #102601)
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/102601
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][lldb-dap] Basic implementation of a deferred request. (PR #140260)
https://github.com/da-viper created
https://github.com/llvm/llvm-project/pull/140260
Fixes #140154
Basic implementation of defering requests.
It no longer depends on a white list of request, So if there is any future
breakpoint types added to the DAP specification. it will not break existing
binary.
It can further be extended to defer depending of the request arguments.
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] Add support for displaying `__float128` variables (PR #98369)
https://github.com/beetrees updated
https://github.com/llvm/llvm-project/pull/98369
>From b96a6a1b6ef96702461a6cf32b361847c318bf8a Mon Sep 17 00:00:00 2001
From: beetrees
Date: Wed, 10 Jul 2024 18:49:45 +0100
Subject: [PATCH] [lldb] Add support for displaying `__float128` variables
---
lldb/bindings/python/python-extensions.swig | 1 +
lldb/docs/python_api_enums.rst| 2 ++
lldb/include/lldb/Symbol/TypeSystem.h | 3 ++-
lldb/include/lldb/lldb-enumerations.h | 7 +-
lldb/source/Commands/CommandObjectMemory.cpp | 2 ++
lldb/source/Core/DumpDataExtractor.cpp| 14 ---
lldb/source/DataFormatters/FormatManager.cpp | 1 +
lldb/source/DataFormatters/VectorType.cpp | 2 ++
.../TypeSystem/Clang/TypeSystemClang.cpp | 25 ++-
.../TypeSystem/Clang/TypeSystemClang.h| 3 ++-
lldb/source/ValueObject/ValueObject.cpp | 5 ++--
lldb/unittests/Core/DumpDataExtractorTest.cpp | 6 +
lldb/unittests/Symbol/TestTypeSystemClang.cpp | 2 ++
13 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/lldb/bindings/python/python-extensions.swig
b/lldb/bindings/python/python-extensions.swig
index 4ba1607c70909..40fa76872ee96 100644
--- a/lldb/bindings/python/python-extensions.swig
+++ b/lldb/bindings/python/python-extensions.swig
@@ -594,6 +594,7 @@ def is_numeric_type(basic_type):
if basic_type == eBasicTypeFloat: return (True,True)
if basic_type == eBasicTypeDouble: return (True,True)
if basic_type == eBasicTypeLongDouble: return (True,True)
+if basic_type == eBasicTypeFloat128: return (True,True)
if basic_type == eBasicTypeFloatComplex: return (True,True)
if basic_type == eBasicTypeDoubleComplex: return (True,True)
if basic_type == eBasicTypeLongDoubleComplex: return (True,True)
diff --git a/lldb/docs/python_api_enums.rst b/lldb/docs/python_api_enums.rst
index b6a2497ea878e..a43a47b8d6985 100644
--- a/lldb/docs/python_api_enums.rst
+++ b/lldb/docs/python_api_enums.rst
@@ -321,6 +321,7 @@ Format
.. py:data:: eFormatInstruction
.. py:data:: eFormatVoid
.. py:data:: eFormatUnicode8
+.. py:data:: eFormatFloat128
.. _DescriptionLevel:
@@ -1045,6 +1046,7 @@ BasicType
.. py:data:: eBasicTypeObjCSel
.. py:data:: eBasicTypeNullPtr
.. py:data:: eBasicTypeOther
+.. py:data:: eBasicTypeFloat128
.. _TraceType:
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h
b/lldb/include/lldb/Symbol/TypeSystem.h
index df87fea32b72a..636bea5adcf83 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -310,7 +310,8 @@ class TypeSystem : public PluginInterface,
// Exploring the type
- virtual const llvm::fltSemantics &GetFloatTypeSemantics(size_t byte_size) =
0;
+ virtual const llvm::fltSemantics &
+ GetFloatTypeSemantics(size_t byte_size, bool prefer_float128) = 0;
virtual llvm::Expected
GetBitSize(lldb::opaque_compiler_type_t type,
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 6d10cc8bcffcb..311a18b850e0a 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -203,6 +203,10 @@ enum Format {
eFormatInstruction, ///< Disassemble an opcode
eFormatVoid,///< Do not print this
eFormatUnicode8,
+ eFormatFloat128, ///< Disambiguate between 128-bit `long double` (which uses
+ ///< `eFormatFloat`) and `__float128` (which uses
+ ///< `eFormatFloat128`). If the value being formatted is not
+ ///< 128 bits, then this is identical to `eFormatFloat`.
kNumFormats
};
@@ -837,7 +841,8 @@ enum BasicType {
eBasicTypeObjCClass,
eBasicTypeObjCSel,
eBasicTypeNullPtr,
- eBasicTypeOther
+ eBasicTypeOther,
+ eBasicTypeFloat128
};
/// Deprecated
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp
b/lldb/source/Commands/CommandObjectMemory.cpp
index 7140333bb3cde..5ccd4be7741e6 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -156,6 +156,7 @@ class OptionGroupReadMemory : public OptionGroup {
case eFormatBinary:
case eFormatFloat:
+case eFormatFloat128:
case eFormatOctal:
case eFormatDecimal:
case eFormatEnum:
@@ -1330,6 +1331,7 @@ class CommandObjectMemoryWrite : public
CommandObjectParsed {
switch (m_format_options.GetFormat()) {
case kNumFormats:
case eFormatFloat: // TODO: add support for floats soon
+ case eFormatFloat128:
case eFormatCharPrintable:
case eFormatBytesWithASCII:
case eFormatComplex:
diff --git a/lldb/source/Core/DumpDataExtractor.cpp
b/lldb/source/Core/DumpDataExtractor.cpp
index 72140736d8877..137a54d7aab29 100644
--- a/lldb/source/Core/DumpDataExtractor.cpp
+++ b/lldb/source/Core/DumpDataExtractor.cpp
@@ -318,14 +318,15 @@ static void printMemoryTags(const DataExtractor &DE,
Stream *s,
}
static c
[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)
@@ -666,7 +667,9 @@ lldb::offset_t lldb_private::DumpDataExtractor( const unsigned format_precision = 0; const llvm::fltSemantics &semantics = - GetFloatSemantics(target_sp, item_byte_size); + item_format == eFormatFloat128 && item_byte_size == 16 + ? llvm::APFloat::IEEEquad() + : GetFloatSemantics(target_sp, item_byte_size); beetrees wrote: I've moved the it inside `GetFloatSemantics`. https://github.com/llvm/llvm-project/pull/98369 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Listen for broadcast classes. (PR #140142)
ashgti wrote: Okay, to summarize my previous comment, I think we could address this in the following ways: 1. Listen for the broadcast class instead of a specific broadcaster. The downside here is we may see events for targets/processes we're not directly interested in. 1. In the setBreakpoint (and friends) functions, delay actually setting the breakpoint until after configuration. The downside here is the added complexity to our startup flow. 1. After `launchCommands`/`attachCommands`, check the existing breakpoints and update the state. The downside here is ensuring we've correctly checked all stateful values after the launch is complete. https://github.com/llvm/llvm-project/pull/140142 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added 32-bit XCOFF Executable support (PR #139875)
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/139875
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][AIX] Added 32-bit XCOFF Executable support (PR #139875)
https://github.com/DhruvSrivastavaX closed https://github.com/llvm/llvm-project/pull/139875 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Listen for broadcast classes. (PR #140142)
ashgti wrote:
> Is it possible to delay _setting_ the breakpoint until we know what the
> target is? Or will that be a problem because attach/launchCommands will
> already resume the process? Could we require that the target is created
> inside `preRunCommands` or `initCommands`?
Previously, we would handle the `launch`/`attach` request when it arrived,
which meant we'd have a target configured by the time the `setBreakpoint`
request was called. Also previously, we would leave the process in a stopped
state until the `configurationDone` request was sent. #138219 adjusted that to
delay handling the `launch`/`attach` until we get the configuration done.
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125 has some
background on that change.
During the startup flow we do need to reply to the `setBreakpoint` requests
before VSCode will send the `configurationDone`. We could just mark the
breakpoints as unverified and not 'really' set them until we finish launching.
That could also work around this issue.
> Can we use the selected target until we've decided on the dap target? I guess
> that still leaves the possibility that the launch commands create multiple
> targets and that you temporarily see events belonging to the wrong target
> before another target was selected, but I'm not sure how to avoid that.
> Unless there's a way to queue up events? I'd need to look at the code in more
> detail to figure out how that works exactly (or ask @jimingham).
Another possible way to handle this would be to iterate over the known
breakpoints after the `attachCommands`/`launchCommands` have finished and check
if we need to update the breakpoint state.
For reference, our launch flow we use is roughly:
```jsonc
{
"type": "lldb-dap",
"request": "launch",
"name": "...",
"initCommands": [
"command source config/lldbinit" // loads python scripts with additional
helpers
],
"launchCommands": [
"!launch --device bazel-bin/path/to/ios_app.ipa"
],
"preLaunchTask": "bazel build //path/to:ios_app"
},
```
The python script is doing roughly:
* unzipping the ipa
* running `simctl install` / `devicectl install`
* `debugger.CreateTarget('', '', '', True)`
* `simctl launch --wait-for-debugger` / `devicectl device process launch
--start-stopped`
* `debugger.GetSelectedTarget().AttachToProcessWithID()`
https://github.com/llvm/llvm-project/pull/140142
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Progress-On-Dap] Have indeterminate progress actually send events. (PR #140162)
@@ -77,16 +77,19 @@ ProgressEvent::Create(uint64_t progress_id,
std::optional message,
if (event.GetEventType() == progressStart && event.GetEventName().empty())
return std::nullopt;
- if (prev_event && prev_event->EqualsForIDE(event))
+ if (prev_event && prev_event->EqualsForIDE(event, total))
return std::nullopt;
return event;
}
-bool ProgressEvent::EqualsForIDE(const ProgressEvent &other) const {
+bool ProgressEvent::EqualsForIDE(const ProgressEvent &other, uint64_t total)
const {
return m_progress_id == other.m_progress_id &&
- m_event_type == other.m_event_type &&
- m_percentage == other.m_percentage;
+ m_event_type == other.m_event_type &&
+ // If we check the percentage of a non-deterministic event
Jlalond wrote:
You're correct, but then we'd be comparing if `null_opt == null_opt`, and no
further updates would be sent. I overlooked this when adding the total, we
should short circuit and ignore the percentage if percentage is a null opt.
https://github.com/llvm/llvm-project/pull/140162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Progress-On-Dap] Have indeterminate progress actually send events. (PR #140162)
@@ -77,16 +77,19 @@ ProgressEvent::Create(uint64_t progress_id,
std::optional message,
if (event.GetEventType() == progressStart && event.GetEventName().empty())
return std::nullopt;
- if (prev_event && prev_event->EqualsForIDE(event))
+ if (prev_event && prev_event->EqualsForIDE(event, total))
return std::nullopt;
return event;
}
-bool ProgressEvent::EqualsForIDE(const ProgressEvent &other) const {
+bool ProgressEvent::EqualsForIDE(const ProgressEvent &other, uint64_t total)
const {
return m_progress_id == other.m_progress_id &&
- m_event_type == other.m_event_type &&
- m_percentage == other.m_percentage;
+ m_event_type == other.m_event_type &&
+ // If we check the percentage of a non-deterministic event
ashgti wrote:
But won't they have different event types if its changed? For a
non-determinitic progress event, it should only go from `m_event_type ==
progressStart` to `m_event_type == progressEnd`, right? If we have 2 starts or
2 ends that feels like the logic got mixed up somewhere else, right?
https://github.com/llvm/llvm-project/pull/140162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
JDevlieghere wrote: Thanks for the summary and especially calling out that the launch and the configuration tracks are happening _in parallel_, I hadn't realized that until now. That explains what the "PAR" stands for in the sequence diagram... Things make a lot more sense now :-) Alright, yeah in that case I see how we can avoid both problems by handling the launch and attach, halting the process, doing the configuration and then sending the response. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
JDevlieghere wrote: One more thing that comes to mind: how confident are we that all existing clients send the launch/attach in parallel with the configuration requests? If we implement what you suggest, we risk a potential deadlock when a client waits for the launch/attach to complete before sending configuration requests or inversely, if the client waits for the initialized event before sending the launch/attach. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Avoid creating temporary instances of std::string (NFC) (PR #140325)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Kazu Hirata (kazutakahirata)
Changes
EmplaceSafeString accepts StringRef for the last parameter, str, and
then internally creates a copy of str via StringRef::str or
llvm::json::fixUTF8, so caller do not need to create their own
temporary instances of std::string.
---
Full diff: https://github.com/llvm/llvm-project/pull/140325.diff
4 Files Affected:
- (modified) lldb/tools/lldb-dap/EventHelper.cpp (+1-1)
- (modified) lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp (+1-1)
- (modified) lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp (+1-1)
- (modified) lldb/tools/lldb-dap/JSONUtils.cpp (+1-1)
``diff
diff --git a/lldb/tools/lldb-dap/EventHelper.cpp
b/lldb/tools/lldb-dap/EventHelper.cpp
index ed2d8700c26b0..c698084836e2f 100644
--- a/lldb/tools/lldb-dap/EventHelper.cpp
+++ b/lldb/tools/lldb-dap/EventHelper.cpp
@@ -93,7 +93,7 @@ void SendProcessEvent(DAP &dap, LaunchMethod launch_method) {
exe_fspec.GetPath(exe_path, sizeof(exe_path));
llvm::json::Object event(CreateEventObject("process"));
llvm::json::Object body;
- EmplaceSafeString(body, "name", std::string(exe_path));
+ EmplaceSafeString(body, "name", exe_path);
const auto pid = dap.target.GetProcess().GetProcessID();
body.try_emplace("systemProcessId", (int64_t)pid);
body.try_emplace("isLocalProcess", true);
diff --git a/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
index 5ce133c33b7e1..e1556846dff19 100644
--- a/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
@@ -205,7 +205,7 @@ void EvaluateRequestHandler::operator()(
lldb::SBError error = value.GetError();
const char *error_cstr = error.GetCString();
if (error_cstr && error_cstr[0])
-EmplaceSafeString(response, "message", std::string(error_cstr));
+EmplaceSafeString(response, "message", error_cstr);
else
EmplaceSafeString(response, "message", "evaluate failed");
} else {
diff --git a/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
index 924ea63ed1593..c1c2adb32a510 100644
--- a/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
@@ -136,7 +136,7 @@ void ExceptionInfoRequestHandler::operator()(
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
-EmplaceSafeString(body, "description", std::string(description));
+EmplaceSafeString(body, "description", description);
}
}
body.try_emplace("breakMode", "always");
diff --git a/lldb/tools/lldb-dap/JSONUtils.cpp
b/lldb/tools/lldb-dap/JSONUtils.cpp
index a8bd672583a5d..714947a4d3b9c 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -905,7 +905,7 @@ llvm::json::Value CreateThreadStopped(DAP &dap,
lldb::SBThread &thread,
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
- EmplaceSafeString(body, "description", std::string(description));
+ EmplaceSafeString(body, "description", description);
}
}
// "threadCausedFocus" is used in tests to validate breaking behavior.
``
https://github.com/llvm/llvm-project/pull/140325
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Avoid creating temporary instances of std::string (NFC) (PR #140325)
https://github.com/kazutakahirata created
https://github.com/llvm/llvm-project/pull/140325
EmplaceSafeString accepts StringRef for the last parameter, str, and
then internally creates a copy of str via StringRef::str or
llvm::json::fixUTF8, so caller do not need to create their own
temporary instances of std::string.
>From efaef78da4a3cdb62db966f79692414c07a172c1 Mon Sep 17 00:00:00 2001
From: Kazu Hirata
Date: Fri, 16 May 2025 17:59:35 -0700
Subject: [PATCH] [lldb-dap] Avoid creating temporary instances of std::string
(NFC)
EmplaceSafeString accepts StringRef for the last parameter, str, and
then internally creates a copy of str via StringRef::str or
llvm::json::fixUTF8, so caller do not need to create their own
temporary instances of std::string.
---
lldb/tools/lldb-dap/EventHelper.cpp | 2 +-
lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp | 2 +-
lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp | 2 +-
lldb/tools/lldb-dap/JSONUtils.cpp | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lldb/tools/lldb-dap/EventHelper.cpp
b/lldb/tools/lldb-dap/EventHelper.cpp
index ed2d8700c26b0..c698084836e2f 100644
--- a/lldb/tools/lldb-dap/EventHelper.cpp
+++ b/lldb/tools/lldb-dap/EventHelper.cpp
@@ -93,7 +93,7 @@ void SendProcessEvent(DAP &dap, LaunchMethod launch_method) {
exe_fspec.GetPath(exe_path, sizeof(exe_path));
llvm::json::Object event(CreateEventObject("process"));
llvm::json::Object body;
- EmplaceSafeString(body, "name", std::string(exe_path));
+ EmplaceSafeString(body, "name", exe_path);
const auto pid = dap.target.GetProcess().GetProcessID();
body.try_emplace("systemProcessId", (int64_t)pid);
body.try_emplace("isLocalProcess", true);
diff --git a/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
index 5ce133c33b7e1..e1556846dff19 100644
--- a/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
@@ -205,7 +205,7 @@ void EvaluateRequestHandler::operator()(
lldb::SBError error = value.GetError();
const char *error_cstr = error.GetCString();
if (error_cstr && error_cstr[0])
-EmplaceSafeString(response, "message", std::string(error_cstr));
+EmplaceSafeString(response, "message", error_cstr);
else
EmplaceSafeString(response, "message", "evaluate failed");
} else {
diff --git a/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
index 924ea63ed1593..c1c2adb32a510 100644
--- a/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
@@ -136,7 +136,7 @@ void ExceptionInfoRequestHandler::operator()(
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
-EmplaceSafeString(body, "description", std::string(description));
+EmplaceSafeString(body, "description", description);
}
}
body.try_emplace("breakMode", "always");
diff --git a/lldb/tools/lldb-dap/JSONUtils.cpp
b/lldb/tools/lldb-dap/JSONUtils.cpp
index a8bd672583a5d..714947a4d3b9c 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -905,7 +905,7 @@ llvm::json::Value CreateThreadStopped(DAP &dap,
lldb::SBThread &thread,
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
- EmplaceSafeString(body, "description", std::string(description));
+ EmplaceSafeString(body, "description", description);
}
}
// "threadCausedFocus" is used in tests to validate breaking behavior.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Formatters] Add --pointer-match-depth option to `type summary add` command. (PR #138209)
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/138209
>From dcb5b2596267d908dea1474164a1fadf1cd23aef Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Thu, 1 May 2025 14:51:24 -0700
Subject: [PATCH 1/5] [lldb][Formatters] Add --pointer-match-depth option to
"type summary add" command.
---
lldb/include/lldb/API/SBTypeSummary.h | 4 +
.../lldb/DataFormatters/FormatClasses.h | 10 +-
.../lldb/DataFormatters/FormatManager.h | 3 +-
.../lldb/DataFormatters/FormattersContainer.h | 8 +-
lldb/include/lldb/DataFormatters/TypeFormat.h | 5 +
.../include/lldb/DataFormatters/TypeSummary.h | 17 ++-
.../lldb/DataFormatters/TypeSynthetic.h | 5 +
lldb/source/API/SBTypeSummary.cpp | 16 +++
lldb/source/Commands/CommandObjectType.cpp| 27 +++--
lldb/source/Commands/Options.td | 4 +
lldb/source/DataFormatters/FormatManager.cpp | 40 ---
.../source/DataFormatters/TypeCategoryMap.cpp | 5 +-
lldb/source/DataFormatters/TypeSummary.cpp| 37 ---
.../data-formatter-ptr-matching/Makefile | 4 +
.../TestDataFormatterPtrMatching.py | 101 ++
.../data-formatter-ptr-matching/main.cpp | 32 ++
16 files changed, 266 insertions(+), 52 deletions(-)
create mode 100644
lldb/test/API/functionalities/data-formatter/data-formatter-ptr-matching/Makefile
create mode 100644
lldb/test/API/functionalities/data-formatter/data-formatter-ptr-matching/TestDataFormatterPtrMatching.py
create mode 100644
lldb/test/API/functionalities/data-formatter/data-formatter-ptr-matching/main.cpp
diff --git a/lldb/include/lldb/API/SBTypeSummary.h
b/lldb/include/lldb/API/SBTypeSummary.h
index 40fa146b4e31b..b6869e53a39e7 100644
--- a/lldb/include/lldb/API/SBTypeSummary.h
+++ b/lldb/include/lldb/API/SBTypeSummary.h
@@ -109,6 +109,10 @@ class SBTypeSummary {
void SetFunctionCode(const char *data);
+ uint32_t GetPtrMatchDepth();
+
+ void SetPtrMatchDepth(uint32_t ptr_match_depth);
+
uint32_t GetOptions();
void SetOptions(uint32_t);
diff --git a/lldb/include/lldb/DataFormatters/FormatClasses.h
b/lldb/include/lldb/DataFormatters/FormatClasses.h
index a6bc3a3542536..89d74649ecc64 100644
--- a/lldb/include/lldb/DataFormatters/FormatClasses.h
+++ b/lldb/include/lldb/DataFormatters/FormatClasses.h
@@ -76,9 +76,10 @@ class FormattersMatchCandidate {
FormattersMatchCandidate(ConstString name,
ScriptInterpreter *script_interpreter, TypeImpl
type,
- Flags flags)
+ Flags flags, uint32_t ptr_stripped_depth = 0)
: m_type_name(name), m_script_interpreter(script_interpreter),
-m_type(type), m_flags(flags) {}
+m_type(type), m_flags(flags), m_ptr_stripped_depth(ptr_stripped_depth)
{
+ }
~FormattersMatchCandidate() = default;
@@ -96,6 +97,8 @@ class FormattersMatchCandidate {
bool DidStripTypedef() const { return m_flags.stripped_typedef; }
+ uint32_t GetPtrStrippedDepth() const { return m_ptr_stripped_depth; }
+
template
bool IsMatch(const std::shared_ptr &formatter_sp) const {
if (!formatter_sp)
@@ -104,6 +107,8 @@ class FormattersMatchCandidate {
return false;
if (formatter_sp->SkipsPointers() && DidStripPointer())
return false;
+if (formatter_sp->GetPtrMatchDepth() < GetPtrStrippedDepth())
+ return false;
if (formatter_sp->SkipsReferences() && DidStripReference())
return false;
return true;
@@ -116,6 +121,7 @@ class FormattersMatchCandidate {
ScriptInterpreter *m_script_interpreter;
TypeImpl m_type;
Flags m_flags;
+ uint32_t m_ptr_stripped_depth;
};
typedef std::vector FormattersMatchVector;
diff --git a/lldb/include/lldb/DataFormatters/FormatManager.h
b/lldb/include/lldb/DataFormatters/FormatManager.h
index db2fe99c44caf..9e24f7b722407 100644
--- a/lldb/include/lldb/DataFormatters/FormatManager.h
+++ b/lldb/include/lldb/DataFormatters/FormatManager.h
@@ -180,7 +180,8 @@ class FormatManager : public IFormatChangeListener {
lldb::DynamicValueType use_dynamic,
FormattersMatchVector &entries,
FormattersMatchCandidate::Flags current_flags,
- bool root_level = false);
+ bool root_level = false,
+ uint32_t ptr_stripped_depth = 0);
std::atomic m_last_revision;
FormatCache m_format_cache;
diff --git a/lldb/include/lldb/DataFormatters/FormattersContainer.h
b/lldb/include/lldb/DataFormatters/FormattersContainer.h
index 7898621fd18af..f7465fc65538d 100644
--- a/lldb/include/lldb/DataFormatters/FormattersContainer.h
+++ b/lldb/include/lldb/DataFormatters/FormattersContainer.h
@@ -193,12 +193,10 @@ template class FormattersContainer {
bool Get(const FormattersMatchVector &candidates, ValueSP &entry) {
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
JDevlieghere wrote: I haven't looked at the code yet. I was re-reading the launch sequence part of the spec [1] to make sure this still complies, and I believe it does because the spec talks about _responding_ to the request, not about _handling_ it. > After the response to configurationDone is sent, the debug adapter may > respond to the launch or attach request, and then the debug session has > started. That said, does this actually solve the underlying problems? We know that VS Code sends the launch and attach request before configuration done. It's equally valid to not do that, and do things the way they're shown in the sequence diagram, where you set breakpoints, then configuration done, then launch or attach. Won't that still hit the same problem? [1] https://microsoft.github.io/debug-adapter-protocol/overview https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
ashgti wrote: > That said, does this actually solve the underlying problems? We know that VS > Code sends the launch and attach request before configuration done. It's > equally valid to not do that, and do things the way they're shown in the > sequence diagram, where you set breakpoints, then configuration done, then > launch or attach. Won't that still hit the same problem? I think there are 2 specific problems that we have after ba29e60f9abd5e883579bb78db13fc5a7588. 1. The pending request filter is somewhat fragile and for @da-viper use case of implementing support for [supportsDataBreakpointBytes](https://microsoft.github.io/debug-adapter-protocol//specification.html#Requests_DataBreakpointInfo) they're running into issues trying to respond to the `dataBreakpointInfo` request without access to a valid target but by not responding to the request, we're not getting `configurationDone`. 2. With the new launch flow, we're setting breakpoints before we've created a target, which is why I'm seeing us missing breakpoint events now when we used to not miss with `launchCommands`. As for the sequence, the flow has 2 parallel tracks that are independently triggered. The overall flow is: * After capabilities are returned from the initialize request trigger the `request launch` or `request attach` * After adapter sends `event initialized`, trigger the `setBreakpoints`, `setFunctionBreakpoints`, `setExceptionBreakpoints `, `setDataBreakpoints`, etc. followed by `configurationDone`. We're actually triggering the configuration flow by sending `event initialized` so we can adjust when that happens. Per the spec: > the debug adapter is expected to send an > [initialized](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Initialized) > event to the development tool to announce that it is ready to accept > configuration requests. With this approach a debug adapter does not have to > implement a buffering strategy for configuration information. Maybe we should look at moving the `initialized` event to after we've responded to the `launch`/`attach` commands instead of buffering or making them async. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][ELF Core] Support all the Generic (Negative) SI Codes. (PR #140150)
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140150
>From 86ec6c076b9cf8e7afeb7d6bb0e334434f6e0d9e Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 13:57:11 -0700
Subject: [PATCH 1/7] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSignals.h | 6 --
.../Plugins/Process/Utility/LinuxSignals.cpp| 17 ++---
.../Plugins/Process/elf-core/ThreadElfCore.cpp | 10 +++---
.../Plugins/Process/elf-core/ThreadElfCore.h| 6 ++
lldb/source/Target/UnixSignals.cpp | 9 +++--
5 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/lldb/include/lldb/Target/UnixSignals.h
b/lldb/include/lldb/Target/UnixSignals.h
index b3605ccefddbe..a1807d69f329b 100644
--- a/lldb/include/lldb/Target/UnixSignals.h
+++ b/lldb/include/lldb/Target/UnixSignals.h
@@ -36,7 +36,9 @@ class UnixSignals {
std::optional code = std::nullopt,
std::optional addr = std::nullopt,
std::optional lower = std::nullopt,
- std::optional upper = std::nullopt) const;
+ std::optional upper = std::nullopt,
+ std::optional pid = std::nullopt,
+ std::optional uid = std::nullopt) const;
bool SignalIsValid(int32_t signo) const;
@@ -105,7 +107,7 @@ class UnixSignals {
llvm::StringRef description,
llvm::StringRef alias = llvm::StringRef());
- enum SignalCodePrintOption { None, Address, Bounds };
+ enum SignalCodePrintOption { None, Address, Bounds, Sender };
// Instead of calling this directly, use a ADD_SIGCODE macro to get compile
// time checks when on the native platform.
diff --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 9c4fe55147a28..25d4e4609bbb8 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -38,6 +38,17 @@
#define ADD_SIGCODE(signal_name, signal_value, code_name, code_value, ...)
\
AddSignalCode(signal_value, code_value, __VA_ARGS__)
#endif /* if defined(__linux__) && !defined(__mips__) */
+// See siginfo.h in the Linux Kernel, these codes can be sent for any signal.
+#define ADD_LINUX_SIGNAL(signo, name, ...) \
+ AddSignal(signo, name, __VA_ARGS__); \
+ ADD_SIGCODE(signo, signo, SI_QUEUE, -1, "sent by sigqueue"); \
+ ADD_SIGCODE(signo, signo, SI_TIMER, -2, "sent by timer expiration"); \
+ ADD_SIGCODE(signo, signo, SI_MESGQ, -3, "sent by real time mesq state
change"); \
+ ADD_SIGCODE(signo, signo, SI_ASYNCIO, -4, "sent by AIO completion"); \
+ ADD_SIGCODE(signo, signo, SI_SIGIO, -5, "sent by queued SIGIO"); \
+ ADD_SIGCODE(signo, signo, SI_TKILL, -6, "sent by tkill system call"); \
+ ADD_SIGCODE(signo, signo, SI_DETHREAD, -7, "sent by execve() killing
subsidiary threads"); \
+ ADD_SIGCODE(signo, signo, SI_ASYNCNL, -60, "sent by glibc async name lookup
completion");
using namespace lldb_private;
@@ -46,9 +57,9 @@ LinuxSignals::LinuxSignals() : UnixSignals() { Reset(); }
void LinuxSignals::Reset() {
m_signals.clear();
// clang-format off
- //SIGNO NAMESUPPRESS STOPNOTIFY DESCRIPTION
- //== == == ==
===
- AddSignal(1, "SIGHUP", false,true, true, "hangup");
+ // SIGNO NAMESUPPRESS STOPNOTIFY
DESCRIPTION
+ // == == == ==
===
+ ADD_LINUX_SIGNAL(1, "SIGHUP", false,true, true, "hangup");
AddSignal(2, "SIGINT", true, true, true, "interrupt");
AddSignal(3, "SIGQUIT", false,true, true, "quit");
diff --git a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
index a0cd0ee5025bd..267879a473463 100644
--- a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -584,9 +584,13 @@ Status ELFLinuxSigInfo::Parse(const DataExtractor &data,
const ArchSpec &arch,
// 64b ELF have a 4 byte pad.
if (data.GetAddressByteSize() == 8)
offset += 4;
- // Not every stop signal has a valid address, but that will get resolved in
- // the unix_signals.GetSignalDescription() call below.
- if (unix_signals.GetShouldStop(si_signo)) {
+
+ if (si_code < 0) {
+ sigfault.kill._pid = data.GetU32(&offset);
+ sigfault.kill._uid = data.GetU32(&offset);
+ } else if (unix_signals.GetShouldStop(si_signo)) {
+// Not every stop signal has a valid address, but that will get resolved in
+// the unix_signals.GetSignalDescription() call below.
// Instead of memcpy we call all these individu
[Lldb-commits] [lldb] [LLDB][ELF Core] Support all the Generic (Negative) SI Codes. (PR #140150)
Jlalond wrote: @labath I refactored to the best of my ability the signal parsing. Thankfully even getting `thread siginfo` working. However I'm unhappy with how I'm handling the ValueObject in the Linux Signals, I couldn't find an easy way to make this into some generic siginfo linux type, so I'm directly accessing members. While it's good I made a better way of doing this, I feel this is worse in terms of safety due to having to explore the ValueObject hierarchy. Any advice here? Secondly, while testing I found the layout in the valueobject differs to the `siginfo_t` on my machine in some subtle ways. Even if the Core was generated on my machine. https://github.com/llvm/llvm-project/pull/140150 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Progress-On-Dap] Have indeterminate progress actually send events. (PR #140162)
@@ -77,16 +77,19 @@ ProgressEvent::Create(uint64_t progress_id,
std::optional message,
if (event.GetEventType() == progressStart && event.GetEventName().empty())
return std::nullopt;
- if (prev_event && prev_event->EqualsForIDE(event))
+ if (prev_event && prev_event->EqualsForIDE(event, total))
return std::nullopt;
return event;
}
-bool ProgressEvent::EqualsForIDE(const ProgressEvent &other) const {
+bool ProgressEvent::EqualsForIDE(const ProgressEvent &other, uint64_t total)
const {
return m_progress_id == other.m_progress_id &&
- m_event_type == other.m_event_type &&
- m_percentage == other.m_percentage;
+ m_event_type == other.m_event_type &&
+ // If we check the percentage of a non-deterministic event
Jlalond wrote:
First, let me apologize for being overly brief in my explanation. You're
correct @ashgti, but now imagine all the updates.
Let's say we're indexing dwarf, you'll get the start, *the first update* and
then the end.
As an extreme hypothetical, if this takes 30 minutes you will have 0 progress
actually sent to the progress bar in VSCode resulting in what appears to be a
hang of LLDB.
So, for non-deterministic events we want to update for every time window. DAP
limits to 250 ms, which I think is fine. I might need to change the equals
check now that I spell this out but I hope this explains the intent!
https://github.com/llvm/llvm-project/pull/140162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140299
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH 1/3] [lldb-dap] Adjusting startup flow to better handle async
operations.
This introduces an `AsyncRequestHandler` and partially reverse the changes from
ba29e60f9abd5e883579bb78db13fc5a7588 in that the `launch` and `attach`
commands now run when we receive them. We wait to send the reply until we get
the `configurationDone` request.
---
lldb/tools/lldb-dap/DAP.cpp | 49 ++---
lldb/tools/lldb-dap/DAP.h | 22 ++-
lldb/tools/lldb-dap/EventHelper.cpp | 2 +-
.../lldb-dap/Handler/AttachRequestHandler.cpp | 69 +++
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 61 +++
.../tools/lldb-dap/Handler/RequestHandler.cpp | 31
lldb/tools/lldb-dap/Handler/RequestHandler.h | 168 +++---
7 files changed, 241 insertions(+), 161 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 56a0c38b00037..416661e98c21f 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -120,11 +120,12 @@ DAP::DAP(Log *log, const ReplMode default_repl_mode,
: log(log), transport(transport), broadcaster("lldb-dap"),
exception_breakpoints(), focus_tid(LLDB_INVALID_THREAD_ID),
stop_at_entry(false), is_attach(false),
- restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done(false),
+ restarting_process_id(LLDB_INVALID_PROCESS_ID),
waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
- reverse_request_seq(0), repl_mode(default_repl_mode) {
+ reverse_request_seq(0), repl_mode(default_repl_mode),
+ m_configuration_done(false) {
configuration.preInitCommands = std::move(pre_init_commands);
RegisterRequests();
}
@@ -916,20 +917,10 @@ llvm::Error DAP::Loop() {
return errWrapper;
}
- // The launch sequence is special and we need to carefully handle
- // packets in the right order. Until we've handled configurationDone,
- bool add_to_pending_queue = false;
-
if (const protocol::Request *req =
- std::get_if(&*next)) {
-llvm::StringRef command = req->command;
-if (command == "disconnect")
- disconnecting = true;
-if (!configuration_done)
- add_to_pending_queue =
- command != "initialize" && command != "configurationDone" &&
- command != "disconnect" && !command.ends_with("Breakpoints");
- }
+ std::get_if(&*next);
+ req && req->command == "disconnect")
+disconnecting = true;
const std::optional cancel_args =
getArgumentsIfRequest(*next, "cancel");
@@ -956,8 +947,7 @@ llvm::Error DAP::Loop() {
{
std::lock_guard guard(m_queue_mutex);
-auto &queue = add_to_pending_queue ? m_pending_queue : m_queue;
-queue.push_back(std::move(*next));
+m_queue.push_back(std::move(*next));
}
m_queue_cv.notify_one();
}
@@ -1255,14 +1245,25 @@ void DAP::SetConfiguration(const
protocol::Configuration &config,
SetThreadFormat(*configuration.customThreadFormat);
}
+bool DAP::GetConfigurationDone() {
+ std::lock_guard guard(m_configuration_done_mutex);
+ return m_configuration_done;
+}
+
void DAP::SetConfigurationDone() {
- {
-std::lock_guard guard(m_queue_mutex);
-std::copy(m_pending_queue.begin(), m_pending_queue.end(),
- std::front_inserter(m_queue));
-configuration_done = true;
- }
- m_queue_cv.notify_all();
+ std::lock_guard guard(m_configuration_done_mutex);
+ m_configuration_done = true;
+ for (auto &cb : m_configuration_done_callbacks)
+cb();
+ m_configuration_done_callbacks.clear();
+}
+
+void DAP::OnConfigurationDone(llvm::unique_function &&callback) {
+ std::lock_guard guard(m_configuration_done_mutex);
+ if (m_configuration_done)
+callback();
+ else
+m_configuration_done_callbacks.emplace_back(std::move(callback));
}
void DAP::SetFrameFormat(llvm::StringRef format) {
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index c1a1130b1e59f..4d170ba4ec920 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -187,7 +187,6 @@ struct DAP {
// shutting down the entire adapter. When we're restarting, we keep the id of
// the old process here so we can detect this case and keep running.
lldb::pid_t restarting_process_id;
- bool configuration_done;
bool waiting_for_run_in_terminal;
ProgressEventReporter progress_event_reporter;
// Keep track of the last stop thread index IDs as threads won't g
[Lldb-commits] [lldb] [lldb][lldb-dap] Basic implementation of a deferred request. (PR #140260)
da-viper wrote:
> Would it be possible to have the RequestHandlers advertise whether or not
> they should be deferred until the configuration is done (e.g.
> DeferredUntilConfigurationDone), and keep the latter an implementation detail
> of the DAP class? And strictly handle deferring at the queue level?
Yes it can,
> What I don't like is how this introduces more statefulness, especially in the
> request handlers. The queueing/deferring logic isn't trivial and I would
> strongly prefer if we could keep it centralized as much as possible. With
> this PR we end up with both a separate queue and a method that makes the Run
> operation behaves differently depending on the global DAP state (i.e. if
> we've send the configuration request).
The plan is to partially resolve the request and then completing the request
later on. for example.
with the launch argument, the new method will be
`optional DeferUntilConfig(
const Arguments &arguments, bool &defer_request)`
```cpp
std::optional LaunchRequestHandler::DeferUntilConfig(
const LaunchRequestArguments &arguments, bool &defer_request) const {
// setups the target and initcommands.
if (LaunchResponse err = PreLaunch(arguments)) {
return err;
}
defer_request = !dap.configuration_done;
return std::nullopt;
}
```
since this it is then deferred it will then complete the remaining request
after the configuration is done. like so
```cpp
Error LaunchRequestHandler::Run(const LaunchRequestArguments &arguments) const {
if (Error err = dap.RunPreRunCommands())
return err;
if (Error err = LaunchProcess(arguments))
return err;
dap.RunPostRunCommands();
return Error::success();
}
```
The could potentially fix the breakpoints problem and also launch after
configuration. Not 100% sure this is the best way hence why I have not included
the commit.
https://github.com/llvm/llvm-project/pull/140260
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/140299
This introduces an `AsyncRequestHandler` and partially reverse the changes from
ba29e60f9abd5e883579bb78db13fc5a7588 in that the `launch` and `attach`
commands now run when we receive them. We wait to send the reply until we get
the `configurationDone` request.
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH] [lldb-dap] Adjusting startup flow to better handle async
operations.
This introduces an `AsyncRequestHandler` and partially reverse the changes from
ba29e60f9abd5e883579bb78db13fc5a7588 in that the `launch` and `attach`
commands now run when we receive them. We wait to send the reply until we get
the `configurationDone` request.
---
lldb/tools/lldb-dap/DAP.cpp | 49 ++---
lldb/tools/lldb-dap/DAP.h | 22 ++-
lldb/tools/lldb-dap/EventHelper.cpp | 2 +-
.../lldb-dap/Handler/AttachRequestHandler.cpp | 69 +++
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 61 +++
.../tools/lldb-dap/Handler/RequestHandler.cpp | 31
lldb/tools/lldb-dap/Handler/RequestHandler.h | 168 +++---
7 files changed, 241 insertions(+), 161 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 56a0c38b00037..416661e98c21f 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -120,11 +120,12 @@ DAP::DAP(Log *log, const ReplMode default_repl_mode,
: log(log), transport(transport), broadcaster("lldb-dap"),
exception_breakpoints(), focus_tid(LLDB_INVALID_THREAD_ID),
stop_at_entry(false), is_attach(false),
- restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done(false),
+ restarting_process_id(LLDB_INVALID_PROCESS_ID),
waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
- reverse_request_seq(0), repl_mode(default_repl_mode) {
+ reverse_request_seq(0), repl_mode(default_repl_mode),
+ m_configuration_done(false) {
configuration.preInitCommands = std::move(pre_init_commands);
RegisterRequests();
}
@@ -916,20 +917,10 @@ llvm::Error DAP::Loop() {
return errWrapper;
}
- // The launch sequence is special and we need to carefully handle
- // packets in the right order. Until we've handled configurationDone,
- bool add_to_pending_queue = false;
-
if (const protocol::Request *req =
- std::get_if(&*next)) {
-llvm::StringRef command = req->command;
-if (command == "disconnect")
- disconnecting = true;
-if (!configuration_done)
- add_to_pending_queue =
- command != "initialize" && command != "configurationDone" &&
- command != "disconnect" && !command.ends_with("Breakpoints");
- }
+ std::get_if(&*next);
+ req && req->command == "disconnect")
+disconnecting = true;
const std::optional cancel_args =
getArgumentsIfRequest(*next, "cancel");
@@ -956,8 +947,7 @@ llvm::Error DAP::Loop() {
{
std::lock_guard guard(m_queue_mutex);
-auto &queue = add_to_pending_queue ? m_pending_queue : m_queue;
-queue.push_back(std::move(*next));
+m_queue.push_back(std::move(*next));
}
m_queue_cv.notify_one();
}
@@ -1255,14 +1245,25 @@ void DAP::SetConfiguration(const
protocol::Configuration &config,
SetThreadFormat(*configuration.customThreadFormat);
}
+bool DAP::GetConfigurationDone() {
+ std::lock_guard guard(m_configuration_done_mutex);
+ return m_configuration_done;
+}
+
void DAP::SetConfigurationDone() {
- {
-std::lock_guard guard(m_queue_mutex);
-std::copy(m_pending_queue.begin(), m_pending_queue.end(),
- std::front_inserter(m_queue));
-configuration_done = true;
- }
- m_queue_cv.notify_all();
+ std::lock_guard guard(m_configuration_done_mutex);
+ m_configuration_done = true;
+ for (auto &cb : m_configuration_done_callbacks)
+cb();
+ m_configuration_done_callbacks.clear();
+}
+
+void DAP::OnConfigurationDone(llvm::unique_function &&callback) {
+ std::lock_guard guard(m_configuration_done_mutex);
+ if (m_configuration_done)
+callback();
+ else
+m_configuration_done_callbacks.emplace_back(std::move(callback));
}
void DAP::SetFrameFormat(llvm::StringRef format) {
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index c1a1130b1e59f..4d170ba4ec920 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -187,7 +187,6 @@ struct DAP {
// shutting down the entire adapter. When we're restarting, we keep the id of
// the old process here s
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
ashgti wrote: @JDevlieghere @da-viper I think this may work to resolve https://github.com/llvm/llvm-project/issues/140154 and the underlying issue I saw in #140142 without needing to change our broadcaster. Leaving as a draft for now, but all the tests are passing with this change. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
da-viper wrote: @ashgti please could you rebase the branch as there is some risv commit that failed on the CI, will test it over the weekend. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140299
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH] [lldb-dap] Adjusting startup flow to better handle async
operations.
This introduces an `AsyncRequestHandler` and partially reverse the changes from
ba29e60f9abd5e883579bb78db13fc5a7588 in that the `launch` and `attach`
commands now run when we receive them. We wait to send the reply until we get
the `configurationDone` request.
---
lldb/tools/lldb-dap/DAP.cpp | 49 ++---
lldb/tools/lldb-dap/DAP.h | 22 ++-
lldb/tools/lldb-dap/EventHelper.cpp | 2 +-
.../lldb-dap/Handler/AttachRequestHandler.cpp | 69 +++
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 61 +++
.../tools/lldb-dap/Handler/RequestHandler.cpp | 31
lldb/tools/lldb-dap/Handler/RequestHandler.h | 168 +++---
7 files changed, 241 insertions(+), 161 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 56a0c38b00037..416661e98c21f 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -120,11 +120,12 @@ DAP::DAP(Log *log, const ReplMode default_repl_mode,
: log(log), transport(transport), broadcaster("lldb-dap"),
exception_breakpoints(), focus_tid(LLDB_INVALID_THREAD_ID),
stop_at_entry(false), is_attach(false),
- restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done(false),
+ restarting_process_id(LLDB_INVALID_PROCESS_ID),
waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
- reverse_request_seq(0), repl_mode(default_repl_mode) {
+ reverse_request_seq(0), repl_mode(default_repl_mode),
+ m_configuration_done(false) {
configuration.preInitCommands = std::move(pre_init_commands);
RegisterRequests();
}
@@ -916,20 +917,10 @@ llvm::Error DAP::Loop() {
return errWrapper;
}
- // The launch sequence is special and we need to carefully handle
- // packets in the right order. Until we've handled configurationDone,
- bool add_to_pending_queue = false;
-
if (const protocol::Request *req =
- std::get_if(&*next)) {
-llvm::StringRef command = req->command;
-if (command == "disconnect")
- disconnecting = true;
-if (!configuration_done)
- add_to_pending_queue =
- command != "initialize" && command != "configurationDone" &&
- command != "disconnect" && !command.ends_with("Breakpoints");
- }
+ std::get_if(&*next);
+ req && req->command == "disconnect")
+disconnecting = true;
const std::optional cancel_args =
getArgumentsIfRequest(*next, "cancel");
@@ -956,8 +947,7 @@ llvm::Error DAP::Loop() {
{
std::lock_guard guard(m_queue_mutex);
-auto &queue = add_to_pending_queue ? m_pending_queue : m_queue;
-queue.push_back(std::move(*next));
+m_queue.push_back(std::move(*next));
}
m_queue_cv.notify_one();
}
@@ -1255,14 +1245,25 @@ void DAP::SetConfiguration(const
protocol::Configuration &config,
SetThreadFormat(*configuration.customThreadFormat);
}
+bool DAP::GetConfigurationDone() {
+ std::lock_guard guard(m_configuration_done_mutex);
+ return m_configuration_done;
+}
+
void DAP::SetConfigurationDone() {
- {
-std::lock_guard guard(m_queue_mutex);
-std::copy(m_pending_queue.begin(), m_pending_queue.end(),
- std::front_inserter(m_queue));
-configuration_done = true;
- }
- m_queue_cv.notify_all();
+ std::lock_guard guard(m_configuration_done_mutex);
+ m_configuration_done = true;
+ for (auto &cb : m_configuration_done_callbacks)
+cb();
+ m_configuration_done_callbacks.clear();
+}
+
+void DAP::OnConfigurationDone(llvm::unique_function &&callback) {
+ std::lock_guard guard(m_configuration_done_mutex);
+ if (m_configuration_done)
+callback();
+ else
+m_configuration_done_callbacks.emplace_back(std::move(callback));
}
void DAP::SetFrameFormat(llvm::StringRef format) {
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index c1a1130b1e59f..4d170ba4ec920 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -187,7 +187,6 @@ struct DAP {
// shutting down the entire adapter. When we're restarting, we keep the id of
// the old process here so we can detect this case and keep running.
lldb::pid_t restarting_process_id;
- bool configuration_done;
bool waiting_for_run_in_terminal;
ProgressEventReporter progress_event_reporter;
// Keep track of the last stop thread index IDs as threads won't go aw
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140299
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH 1/2] [lldb-dap] Adjusting startup flow to better handle async
operations.
This introduces an `AsyncRequestHandler` and partially reverse the changes from
ba29e60f9abd5e883579bb78db13fc5a7588 in that the `launch` and `attach`
commands now run when we receive them. We wait to send the reply until we get
the `configurationDone` request.
---
lldb/tools/lldb-dap/DAP.cpp | 49 ++---
lldb/tools/lldb-dap/DAP.h | 22 ++-
lldb/tools/lldb-dap/EventHelper.cpp | 2 +-
.../lldb-dap/Handler/AttachRequestHandler.cpp | 69 +++
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 61 +++
.../tools/lldb-dap/Handler/RequestHandler.cpp | 31
lldb/tools/lldb-dap/Handler/RequestHandler.h | 168 +++---
7 files changed, 241 insertions(+), 161 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 56a0c38b00037..416661e98c21f 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -120,11 +120,12 @@ DAP::DAP(Log *log, const ReplMode default_repl_mode,
: log(log), transport(transport), broadcaster("lldb-dap"),
exception_breakpoints(), focus_tid(LLDB_INVALID_THREAD_ID),
stop_at_entry(false), is_attach(false),
- restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done(false),
+ restarting_process_id(LLDB_INVALID_PROCESS_ID),
waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
- reverse_request_seq(0), repl_mode(default_repl_mode) {
+ reverse_request_seq(0), repl_mode(default_repl_mode),
+ m_configuration_done(false) {
configuration.preInitCommands = std::move(pre_init_commands);
RegisterRequests();
}
@@ -916,20 +917,10 @@ llvm::Error DAP::Loop() {
return errWrapper;
}
- // The launch sequence is special and we need to carefully handle
- // packets in the right order. Until we've handled configurationDone,
- bool add_to_pending_queue = false;
-
if (const protocol::Request *req =
- std::get_if(&*next)) {
-llvm::StringRef command = req->command;
-if (command == "disconnect")
- disconnecting = true;
-if (!configuration_done)
- add_to_pending_queue =
- command != "initialize" && command != "configurationDone" &&
- command != "disconnect" && !command.ends_with("Breakpoints");
- }
+ std::get_if(&*next);
+ req && req->command == "disconnect")
+disconnecting = true;
const std::optional cancel_args =
getArgumentsIfRequest(*next, "cancel");
@@ -956,8 +947,7 @@ llvm::Error DAP::Loop() {
{
std::lock_guard guard(m_queue_mutex);
-auto &queue = add_to_pending_queue ? m_pending_queue : m_queue;
-queue.push_back(std::move(*next));
+m_queue.push_back(std::move(*next));
}
m_queue_cv.notify_one();
}
@@ -1255,14 +1245,25 @@ void DAP::SetConfiguration(const
protocol::Configuration &config,
SetThreadFormat(*configuration.customThreadFormat);
}
+bool DAP::GetConfigurationDone() {
+ std::lock_guard guard(m_configuration_done_mutex);
+ return m_configuration_done;
+}
+
void DAP::SetConfigurationDone() {
- {
-std::lock_guard guard(m_queue_mutex);
-std::copy(m_pending_queue.begin(), m_pending_queue.end(),
- std::front_inserter(m_queue));
-configuration_done = true;
- }
- m_queue_cv.notify_all();
+ std::lock_guard guard(m_configuration_done_mutex);
+ m_configuration_done = true;
+ for (auto &cb : m_configuration_done_callbacks)
+cb();
+ m_configuration_done_callbacks.clear();
+}
+
+void DAP::OnConfigurationDone(llvm::unique_function &&callback) {
+ std::lock_guard guard(m_configuration_done_mutex);
+ if (m_configuration_done)
+callback();
+ else
+m_configuration_done_callbacks.emplace_back(std::move(callback));
}
void DAP::SetFrameFormat(llvm::StringRef format) {
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index c1a1130b1e59f..4d170ba4ec920 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -187,7 +187,6 @@ struct DAP {
// shutting down the entire adapter. When we're restarting, we keep the id of
// the old process here so we can detect this case and keep running.
lldb::pid_t restarting_process_id;
- bool configuration_done;
bool waiting_for_run_in_terminal;
ProgressEventReporter progress_event_reporter;
// Keep track of the last stop thread index IDs as threads won't g
[Lldb-commits] [lldb] [lldb][AArch64] Fix Apple M4 on Linux (PR #135563)
mstorsjo wrote: > > Therefore, this situation should only be an issue with older kernels, so > > perhaps it not something that regular user mode applications should need to > > worry about (unless specifically wanting to run with older kernels). > > I will test this PR with an older kernel as well. Would be nice if it works > there too. Did you manage to test things with an older kernel, at least on the level of what hwcaps are presented - to confirm you'd get the inconsistent hwcaps in that case (sve2 enabled, sve1 disabled)? https://github.com/llvm/llvm-project/pull/135563 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c02e6ca - [lldb][AIX] Added 32-bit XCOFF Executable support (#139875)
Author: Dhruv Srivastava
Date: 2025-05-16T17:40:13+05:30
New Revision: c02e6ca3b3ea84566800043bb4c29c67eb63f223
URL:
https://github.com/llvm/llvm-project/commit/c02e6ca3b3ea84566800043bb4c29c67eb63f223
DIFF:
https://github.com/llvm/llvm-project/commit/c02e6ca3b3ea84566800043bb4c29c67eb63f223.diff
LOG: [lldb][AIX] Added 32-bit XCOFF Executable support (#139875)
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. https://github.com/llvm/llvm-project/issues/101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601
**Description:**
Adding support for XCOFF 32 bit file format as well in lldb, up to the
point where 64-bit support is implemented.
Added a new test case for the same.
This is an incremental PR on top of the previous couple of XCOFF support
commits.
Added:
lldb/test/Shell/ObjectFile/XCOFF/basic-info32.yaml
Modified:
lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h
Removed:
diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
index 177c360ba..e629355cd40b9 100644
--- a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
@@ -39,7 +39,6 @@ using namespace lldb;
using namespace lldb_private;
LLDB_PLUGIN_DEFINE(ObjectFileXCOFF)
-
// FIXME: target 64bit at this moment.
// Static methods.
@@ -95,10 +94,11 @@ bool ObjectFileXCOFF::CreateBinary() {
Log *log = GetLog(LLDBLog::Object);
- auto binary = llvm::object::ObjectFile::createObjectFile(
- llvm::MemoryBufferRef(toStringRef(m_data.GetData()),
-m_file.GetFilename().GetStringRef()),
- file_magic::xcoff_object_64);
+ auto memory_ref = llvm::MemoryBufferRef(toStringRef(m_data.GetData()),
+ m_file.GetFilename().GetStringRef());
+ llvm::file_magic magic = llvm::identify_magic(memory_ref.getBuffer());
+
+ auto binary = llvm::object::ObjectFile::createObjectFile(memory_ref, magic);
if (!binary) {
LLDB_LOG_ERROR(log, binary.takeError(),
"Failed to create binary for file ({1}): {0}", m_file);
@@ -143,9 +143,9 @@ size_t ObjectFileXCOFF::GetModuleSpecifications(
static uint32_t XCOFFHeaderSizeFromMagic(uint32_t magic) {
switch (magic) {
-// TODO: 32bit not supported.
-// case XCOFF::XCOFF32:
-// return sizeof(struct llvm::object::XCOFFFileHeader32);
+ case XCOFF::XCOFF32:
+return sizeof(struct llvm::object::XCOFFFileHeader32);
+break;
case XCOFF::XCOFF64:
return sizeof(struct llvm::object::XCOFFFileHeader64);
break;
@@ -169,8 +169,9 @@ bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP &data_sp,
}
bool ObjectFileXCOFF::ParseHeader() {
- // Only 64-bit is supported for now
- return m_binary->fileHeader64()->Magic == XCOFF::XCOFF64;
+ if (m_binary->is64Bit())
+return m_binary->fileHeader64()->Magic == XCOFF::XCOFF64;
+ return m_binary->fileHeader32()->Magic == XCOFF::XCOFF32;
}
ByteOrder ObjectFileXCOFF::GetByteOrder() const { return eByteOrderBig; }
@@ -178,8 +179,9 @@ ByteOrder ObjectFileXCOFF::GetByteOrder() const { return
eByteOrderBig; }
bool ObjectFileXCOFF::IsExecutable() const { return true; }
uint32_t ObjectFileXCOFF::GetAddressByteSize() const {
- // 32-bit not supported. return 8 for 64-bit XCOFF::XCOFF64
- return 8;
+ if (m_binary->is64Bit())
+return 8;
+ return 4;
}
AddressClass ObjectFileXCOFF::GetAddressClass(addr_t file_addr) {
@@ -191,20 +193,37 @@ void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
bool ObjectFileXCOFF::IsStripped() { return false; }
void ObjectFileXCOFF::CreateSections(SectionList &unified_section_list) {
+
if (m_sections_up)
return;
m_sections_up = std::make_unique();
- ModuleSP module_sp(GetModule());
+ if (m_binary->is64Bit())
+CreateSectionsWithBitness(unified_section_list);
+ else
+CreateSectionsWithBitness(unified_section_list);
+}
+template
+static auto GetSections(llvm::object::XCOFFObjectFile *binary) {
+ if constexpr (T::Is64Bit)
+return binary->sections64();
+ else
+return binary->sections32();
+}
+
+template
+void ObjectFileXCOFF::CreateSectionsWithBitness(
+SectionList &unified_section_list) {
+ ModuleSP module_sp(GetModule());
if (!module_sp)
return;
std::lock_guard guard(module_sp->GetMutex());
int idx = 0;
- for (const llvm::object::XCOFFSectionHeader64 §ion :
- m_binary->sections64()) {
+ for (const typename T::SectionHeader §ion :
+ GetSections(m_binary.get())) {
ConstString const_sect_name(section.Name);
@@ -253,9 +272,13 @@ UUID ObjectFil
[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (PR #139175)
Sterling-Augustine wrote: Anyone? https://github.com/llvm/llvm-project/pull/139175 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (PR #139175)
jmorse wrote: This disappeared into a black hole in my inbox sorry; step forwards @SLTozer! (We're not rated for the reader-side of things but can probably comment on the writer). https://github.com/llvm/llvm-project/pull/139175 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140331
>From 5c77f71128e01db1a3926d0de06f2d4d55cb80e0 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 18:35:28 -0700
Subject: [PATCH] [lldb-dap] Take two at refactoring the startup sequence.
This is more straight forward refactor of the startup sequence that reverts
parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt,
I ended up removing the pending request queue and not including an
`AsyncReqeustHandler` because I don't think we actually need that at the moment.
The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.
* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and other
config requests are made followed by the `configurationDone` event.
I moved the `initialized` event back to happen in the `PostRun` of the `launch`
or `attach` request handlers. This ensures that we have a valid target by the
time the configuration calls are made. I added also added a few extra
validations that to the `configurationeDone` handler to ensure we're in an
expected state.
I've also fixed up the tests to match the new flow. With the other additional
test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I think we've narrowed
down the main source of test instability that motivated the startup sequence
change.
---
.../test/tools/lldb-dap/dap_server.py | 24 +++---
.../test/tools/lldb-dap/lldbdap_testcase.py | 70 +---
.../TestDAP_breakpointEvents.py | 2 +-
.../tools/lldb-dap/cancel/TestDAP_cancel.py | 4 +-
.../completions/TestDAP_completions.py| 17 ++--
.../tools/lldb-dap/console/TestDAP_console.py | 13 +--
.../console/TestDAP_redirection_to_console.py | 4 +-
.../lldb-dap/coreFile/TestDAP_coreFile.py | 1 +
.../lldb-dap/evaluate/TestDAP_evaluate.py | 1 -
.../tools/lldb-dap/launch/TestDAP_launch.py | 4 +-
.../module-event/TestDAP_module_event.py | 2 +-
.../tools/lldb-dap/module/TestDAP_module.py | 4 +-
.../repl-mode/TestDAP_repl_mode_detection.py | 2 +-
.../tools/lldb-dap/restart/TestDAP_restart.py | 5 +-
.../lldb-dap/send-event/TestDAP_sendEvent.py | 3 +-
.../lldb-dap/stackTrace/TestDAP_stackTrace.py | 2 +-
.../TestDAP_stackTraceDisassemblyDisplay.py | 2 +-
.../startDebugging/TestDAP_startDebugging.py | 2 +-
.../lldb-dap/stop-hooks/TestDAP_stop_hooks.py | 2 +-
.../tools/lldb-dap/threads/TestDAP_threads.py | 5 +-
.../children/TestDAP_variables_children.py| 5 +-
lldb/tools/lldb-dap/DAP.cpp | 29 +--
lldb/tools/lldb-dap/DAP.h | 1 -
.../lldb-dap/Handler/AttachRequestHandler.cpp | 19 +
.../ConfigurationDoneRequestHandler.cpp | 82 ++-
.../Handler/InitializeRequestHandler.cpp | 4 -
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 20 +
lldb/tools/lldb-dap/Handler/RequestHandler.h | 62 --
lldb/tools/lldb-dap/Protocol/ProtocolBase.h | 3 +
.../lldb-dap/Protocol/ProtocolRequests.h | 7 ++
30 files changed, 150 insertions(+), 251 deletions(-)
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index d3589e78b6bc7..70fd0b0c419db 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -133,6 +133,7 @@ def __init__(
self.output_condition = threading.Condition()
self.output: dict[str, list[str]] = {}
self.configuration_done_sent = False
+self.initialized = False
self.frame_scopes = {}
self.init_commands = init_commands
self.disassembled_instructions = {}
@@ -235,6 +236,8 @@ def _handle_recv_packet(self, packet:
Optional[ProtocolMessage]) -> bool:
self.output_condition.release()
# no need to add 'output' event packets to our packets list
return keepGoing
+elif event == "initialized":
+self.initialized = True
elif event == "process":
# When a new process is attached or launched, remember the
# details that are available in the body of the event
@@ -602,7 +605,7 @@ def request_attach(
exitCommands: Optional[list[str]] = None,
terminateCommands: Optional[list[str]] = None,
coreFile: Optional[str] = None,
-stopOnAttach=True,
+stopOnEntry=False,
sourceMap: Optional[Union[list[tuple[str, str]], dict[str, str]]] =
None,
gdbRemotePort: Optional[int] = None,
gdbRemoteHostname: Optional[str] = None,
@@ -629,8 +632,8 @@ def request_attach(
args_dict["attachCommands
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
JDevlieghere wrote: I also found this diagram which covers both cases I had in mind: https://github.com/microsoft/vscode/issues/4902#issuecomment-368583522 https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
ashgti wrote: I think #140331 is a cleaner way to solve this without the need for an `AsyncRequestHandler`. We may still want the `AsyncRequestHandler` in the future, but at least for now, I think we can avoid its added complexity. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/ashgti created https://github.com/llvm/llvm-project/pull/140331 This is more straight forward refactor of the startup sequence that reverts parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt, I ended up removing the pending request queue and not including an `AsyncReqeustHandler` because I don't think we actually need that at the moment. The key is that during the startup flow there are 2 parallel operations happening in the DAP that have different triggers. * The `initialize` request is sent and once the response is received the `launch` or `attach` is sent. * When the `initialized` event is recieved the `setBreakpionts` and other config requests are made followed by the `configurationDone` event. I moved the `initialized` event back to happen in the `PostRun` of the `launch` or `attach` request handlers. This ensures that we have a valid target by the time the configuration calls are made. I added also added a few extra validations that to the `configurationeDone` handler to ensure we're in an expected state. I've also fixed up the tests to match the new flow. With the other additional test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I think we've narrowed down the main source of test instability that motivated the startup sequence change. >From 71c7830f569c0b13045ad4b0301973e606a2f06e Mon Sep 17 00:00:00 2001 From: John Harrison Date: Fri, 16 May 2025 18:35:28 -0700 Subject: [PATCH] [lldb-dap] Take two at refactoring the startup sequence. This is more straight forward refactor of the startup sequence that reverts parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt, I ended up removing the pending request queue and not including an `AsyncReqeustHandler` because I don't think we actually need that at the moment. The key is that during the startup flow there are 2 parallel operations happening in the DAP that have different triggers. * The `initialize` request is sent and once the response is received the `launch` or `attach` is sent. * When the `initialized` event is recieved the `setBreakpionts` and other config requests are made followed by the `configurationDone` event. I moved the `initialized` event back to happen in the `PostRun` of the `launch` or `attach` request handlers. This ensures that we have a valid target by the time the configuration calls are made. I added also added a few extra validations that to the `configurationeDone` handler to ensure we're in an expected state. I've also fixed up the tests to match the new flow. With the other additional test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I think we've narrowed down the main source of test instability that motivated the startup sequence change. --- .../test/tools/lldb-dap/dap_server.py | 24 +++--- .../test/tools/lldb-dap/lldbdap_testcase.py | 70 +--- .../TestDAP_breakpointEvents.py | 2 +- .../tools/lldb-dap/cancel/TestDAP_cancel.py | 4 +- .../completions/TestDAP_completions.py| 17 ++-- .../tools/lldb-dap/console/TestDAP_console.py | 13 +-- .../console/TestDAP_redirection_to_console.py | 4 +- .../lldb-dap/coreFile/TestDAP_coreFile.py | 1 + .../lldb-dap/evaluate/TestDAP_evaluate.py | 1 - .../tools/lldb-dap/launch/TestDAP_launch.py | 3 +- .../module-event/TestDAP_module_event.py | 2 +- .../tools/lldb-dap/module/TestDAP_module.py | 4 +- .../repl-mode/TestDAP_repl_mode_detection.py | 2 +- .../tools/lldb-dap/restart/TestDAP_restart.py | 5 +- .../lldb-dap/send-event/TestDAP_sendEvent.py | 3 +- .../lldb-dap/stackTrace/TestDAP_stackTrace.py | 2 +- .../TestDAP_stackTraceDisassemblyDisplay.py | 2 +- .../startDebugging/TestDAP_startDebugging.py | 2 +- .../lldb-dap/stop-hooks/TestDAP_stop_hooks.py | 2 +- .../tools/lldb-dap/threads/TestDAP_threads.py | 5 +- .../children/TestDAP_variables_children.py| 5 +- lldb/tools/lldb-dap/DAP.cpp | 29 +-- lldb/tools/lldb-dap/DAP.h | 1 - .../lldb-dap/Handler/AttachRequestHandler.cpp | 19 + .../ConfigurationDoneRequestHandler.cpp | 82 ++- .../Handler/InitializeRequestHandler.cpp | 4 - .../lldb-dap/Handler/LaunchRequestHandler.cpp | 20 + lldb/tools/lldb-dap/Handler/RequestHandler.h | 62 -- lldb/tools/lldb-dap/Protocol/ProtocolBase.h | 3 + .../lldb-dap/Protocol/ProtocolRequests.h | 7 ++ 30 files changed, 150 insertions(+), 250 deletions(-) diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py index d3589e78b6bc7..70fd0b0c419db 100644 --- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py +++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py @@ -133,6 +133,7 @@ def __init__( self.output_condition = threading.Condition() self.output: dic
[Lldb-commits] [lldb] Update python.rst (PR #140333)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: None (LauraElanorJones) Changes Fix code block formatting in section "The Decision Point Breakpoint Commands" --- Full diff: https://github.com/llvm/llvm-project/pull/140333.diff 1 Files Affected: - (modified) lldb/docs/use/python.rst (+4-1) ``diff diff --git a/lldb/docs/use/python.rst b/lldb/docs/use/python.rst index d9c29d95708c1..3a919f2a8cdb1 100644 --- a/lldb/docs/use/python.rst +++ b/lldb/docs/use/python.rst @@ -330,9 +330,12 @@ decision to go right: process.Continue() else: print "Here is the problem; going right, should go left!" - Just as a reminder, LLDB is going to take this script and wrap it up in a function, like this: +Just as a reminder, LLDB is going to take this script and wrap it up in a function, like this: + +:: + def some_unique_and_obscure_function_name (frame, bp_loc): global path if path[0] == 'R': `` https://github.com/llvm/llvm-project/pull/140333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
This is more straight forward refactor of the startup sequence that reverts
parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt,
I ended up removing the pending request queue and not including an
`AsyncReqeustHandler` because I don't think we actually need that at the moment.
The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.
* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and other
config requests are made followed by the `configurationDone` event.
I moved the `initialized` event back to happen in the `PostRun` of the `launch`
or `attach` request handlers. This ensures that we have a valid target by the
time the configuration calls are made. I added also added a few extra
validations that to the `configurationeDone` handler to ensure we're in an
expected state.
I've also fixed up the tests to match the new flow. With the other additional
test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I think we've narrowed
down the main source of test instability that motivated the startup sequence
change.
---
Patch is 42.82 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/140331.diff
30 Files Affected:
- (modified) lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
(+10-14)
- (modified)
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py (+3-67)
- (modified)
lldb/test/API/tools/lldb-dap/breakpoint-events/TestDAP_breakpointEvents.py
(+1-1)
- (modified) lldb/test/API/tools/lldb-dap/cancel/TestDAP_cancel.py (+2-2)
- (modified) lldb/test/API/tools/lldb-dap/completions/TestDAP_completions.py
(+6-11)
- (modified) lldb/test/API/tools/lldb-dap/console/TestDAP_console.py (+7-6)
- (modified)
lldb/test/API/tools/lldb-dap/console/TestDAP_redirection_to_console.py (+1-3)
- (modified) lldb/test/API/tools/lldb-dap/coreFile/TestDAP_coreFile.py (+1)
- (modified) lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py (-1)
- (modified) lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py (+2-2)
- (modified) lldb/test/API/tools/lldb-dap/module-event/TestDAP_module_event.py
(+1-1)
- (modified) lldb/test/API/tools/lldb-dap/module/TestDAP_module.py (+2-2)
- (modified)
lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py (+1-1)
- (modified) lldb/test/API/tools/lldb-dap/restart/TestDAP_restart.py (+4-1)
- (modified) lldb/test/API/tools/lldb-dap/send-event/TestDAP_sendEvent.py
(+2-1)
- (modified) lldb/test/API/tools/lldb-dap/stackTrace/TestDAP_stackTrace.py
(+1-1)
- (modified)
lldb/test/API/tools/lldb-dap/stackTraceDisassemblyDisplay/TestDAP_stackTraceDisassemblyDisplay.py
(+1-1)
- (modified)
lldb/test/API/tools/lldb-dap/startDebugging/TestDAP_startDebugging.py (+1-1)
- (modified) lldb/test/API/tools/lldb-dap/stop-hooks/TestDAP_stop_hooks.py
(+1-1)
- (modified) lldb/test/API/tools/lldb-dap/threads/TestDAP_threads.py (+4-1)
- (modified)
lldb/test/API/tools/lldb-dap/variables/children/TestDAP_variables_children.py
(+1-4)
- (modified) lldb/tools/lldb-dap/DAP.cpp (+4-25)
- (modified) lldb/tools/lldb-dap/DAP.h (-1)
- (modified) lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp (+1-18)
- (modified) lldb/tools/lldb-dap/Handler/ConfigurationDoneRequestHandler.cpp
(+43-39)
- (modified) lldb/tools/lldb-dap/Handler/InitializeRequestHandler.cpp (-4)
- (modified) lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp (+1-19)
- (modified) lldb/tools/lldb-dap/Handler/RequestHandler.h (+39-23)
- (modified) lldb/tools/lldb-dap/Protocol/ProtocolBase.h (+3)
- (modified) lldb/tools/lldb-dap/Protocol/ProtocolRequests.h (+7)
``diff
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index d3589e78b6bc7..70fd0b0c419db 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -133,6 +133,7 @@ def __init__(
self.output_condition = threading.Condition()
self.output: dict[str, list[str]] = {}
self.configuration_done_sent = False
+self.initialized = False
self.frame_scopes = {}
self.init_commands = init_commands
self.disassembled_instructions = {}
@@ -235,6 +236,8 @@ def _handle_recv_packet(self, packet:
Optional[ProtocolMessage]) -> bool:
self.output_condition.release()
# no need to add 'output' event packets to our packets list
return keepGoing
+elif event == "initialized":
+self.initialized = True
elif event == "process":
# When a new p
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/ashgti ready_for_review https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
ashgti wrote: Looks like all the tests are passing on linux and for me locally as well. > The only thing I don't like is that the configurationDone is now once again > implicit. In a future PR, I'd love to move the tests to a model where we > specify that explicitly after doing the breakpoints (and automatically catch > cases where someone forgets, like your PR from earlier this week). I'm happy > to sign myself up to do that work. That sounds great! I think that would help clean up the tests a bit by making it a bit more explicit about when they're done configuring things. https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update python.rst (PR #140333)
https://github.com/LauraElanorJones created https://github.com/llvm/llvm-project/pull/140333 Fix code block formatting in section "The Decision Point Breakpoint Commands" >From 7d235fe77df46cfe2525cbed2a9944a6f208a613 Mon Sep 17 00:00:00 2001 From: LauraElanorJones <164247463+lauraelanorjo...@users.noreply.github.com> Date: Fri, 16 May 2025 18:49:02 -0700 Subject: [PATCH] Update python.rst Fix code block formatting in section "The Decision Point Breakpoint Commands" --- lldb/docs/use/python.rst | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lldb/docs/use/python.rst b/lldb/docs/use/python.rst index d9c29d95708c1..3a919f2a8cdb1 100644 --- a/lldb/docs/use/python.rst +++ b/lldb/docs/use/python.rst @@ -330,9 +330,12 @@ decision to go right: process.Continue() else: print "Here is the problem; going right, should go left!" - Just as a reminder, LLDB is going to take this script and wrap it up in a function, like this: +Just as a reminder, LLDB is going to take this script and wrap it up in a function, like this: + +:: + def some_unique_and_obscure_function_name (frame, bp_loc): global path if path[0] == 'R': ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140331
>From 5c77f71128e01db1a3926d0de06f2d4d55cb80e0 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 18:35:28 -0700
Subject: [PATCH 1/2] [lldb-dap] Take two at refactoring the startup sequence.
This is more straight forward refactor of the startup sequence that reverts
parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt,
I ended up removing the pending request queue and not including an
`AsyncReqeustHandler` because I don't think we actually need that at the moment.
The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.
* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and other
config requests are made followed by the `configurationDone` event.
I moved the `initialized` event back to happen in the `PostRun` of the `launch`
or `attach` request handlers. This ensures that we have a valid target by the
time the configuration calls are made. I added also added a few extra
validations that to the `configurationeDone` handler to ensure we're in an
expected state.
I've also fixed up the tests to match the new flow. With the other additional
test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I think we've narrowed
down the main source of test instability that motivated the startup sequence
change.
---
.../test/tools/lldb-dap/dap_server.py | 24 +++---
.../test/tools/lldb-dap/lldbdap_testcase.py | 70 +---
.../TestDAP_breakpointEvents.py | 2 +-
.../tools/lldb-dap/cancel/TestDAP_cancel.py | 4 +-
.../completions/TestDAP_completions.py| 17 ++--
.../tools/lldb-dap/console/TestDAP_console.py | 13 +--
.../console/TestDAP_redirection_to_console.py | 4 +-
.../lldb-dap/coreFile/TestDAP_coreFile.py | 1 +
.../lldb-dap/evaluate/TestDAP_evaluate.py | 1 -
.../tools/lldb-dap/launch/TestDAP_launch.py | 4 +-
.../module-event/TestDAP_module_event.py | 2 +-
.../tools/lldb-dap/module/TestDAP_module.py | 4 +-
.../repl-mode/TestDAP_repl_mode_detection.py | 2 +-
.../tools/lldb-dap/restart/TestDAP_restart.py | 5 +-
.../lldb-dap/send-event/TestDAP_sendEvent.py | 3 +-
.../lldb-dap/stackTrace/TestDAP_stackTrace.py | 2 +-
.../TestDAP_stackTraceDisassemblyDisplay.py | 2 +-
.../startDebugging/TestDAP_startDebugging.py | 2 +-
.../lldb-dap/stop-hooks/TestDAP_stop_hooks.py | 2 +-
.../tools/lldb-dap/threads/TestDAP_threads.py | 5 +-
.../children/TestDAP_variables_children.py| 5 +-
lldb/tools/lldb-dap/DAP.cpp | 29 +--
lldb/tools/lldb-dap/DAP.h | 1 -
.../lldb-dap/Handler/AttachRequestHandler.cpp | 19 +
.../ConfigurationDoneRequestHandler.cpp | 82 ++-
.../Handler/InitializeRequestHandler.cpp | 4 -
.../lldb-dap/Handler/LaunchRequestHandler.cpp | 20 +
lldb/tools/lldb-dap/Handler/RequestHandler.h | 62 --
lldb/tools/lldb-dap/Protocol/ProtocolBase.h | 3 +
.../lldb-dap/Protocol/ProtocolRequests.h | 7 ++
30 files changed, 150 insertions(+), 251 deletions(-)
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index d3589e78b6bc7..70fd0b0c419db 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -133,6 +133,7 @@ def __init__(
self.output_condition = threading.Condition()
self.output: dict[str, list[str]] = {}
self.configuration_done_sent = False
+self.initialized = False
self.frame_scopes = {}
self.init_commands = init_commands
self.disassembled_instructions = {}
@@ -235,6 +236,8 @@ def _handle_recv_packet(self, packet:
Optional[ProtocolMessage]) -> bool:
self.output_condition.release()
# no need to add 'output' event packets to our packets list
return keepGoing
+elif event == "initialized":
+self.initialized = True
elif event == "process":
# When a new process is attached or launched, remember the
# details that are available in the body of the event
@@ -602,7 +605,7 @@ def request_attach(
exitCommands: Optional[list[str]] = None,
terminateCommands: Optional[list[str]] = None,
coreFile: Optional[str] = None,
-stopOnAttach=True,
+stopOnEntry=False,
sourceMap: Optional[Union[list[tuple[str, str]], dict[str, str]]] =
None,
gdbRemotePort: Optional[int] = None,
gdbRemoteHostname: Optional[str] = None,
@@ -629,8 +632,8 @@ def request_attach(
args_dict["attachComm
[Lldb-commits] [lldb] Update python.rst (PR #140333)
github-actions[bot] wrote: ⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo. Please turn off [Keep my email addresses private](https://github.com/settings/emails) setting in your account. See [LLVM Discourse](https://discourse.llvm.org/t/hidden-emails-on-github-should-we-do-something-about-it) for more information. https://github.com/llvm/llvm-project/pull/140333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update python.rst (PR #140333)
github-actions[bot] wrote: @LauraElanorJones Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with a build, you may receive a report in an email or a comment on this PR. Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues. How to do this, and the rest of the post-merge process, is covered in detail [here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr). If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of [LLVM development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy). You can fix your changes and open a new PR to merge them again. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! https://github.com/llvm/llvm-project/pull/140333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 0e0b501 - [lldb-dap] Take two at refactoring the startup sequence. (#140331)
Author: John Harrison
Date: 2025-05-16T19:28:34-07:00
New Revision: 0e0b501bf53677105b539fa4f84cbfb76c46f74d
URL:
https://github.com/llvm/llvm-project/commit/0e0b501bf53677105b539fa4f84cbfb76c46f74d
DIFF:
https://github.com/llvm/llvm-project/commit/0e0b501bf53677105b539fa4f84cbfb76c46f74d.diff
LOG: [lldb-dap] Take two at refactoring the startup sequence. (#140331)
This is more straight forward refactor of the startup sequence that
reverts parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my
previous attempt, I ended up removing the pending request queue and not
including an `AsyncReqeustHandler` because I don't think we actually
need that at the moment.
The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.
* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and
other config requests are made followed by the `configurationDone`
event.
I moved the `initialized` event back to happen in the `PostRun` of the
`launch` or `attach` request handlers. This ensures that we have a valid
target by the time the configuration calls are made. I added also added
a few extra validations that to the `configurationeDone` handler to
ensure we're in an expected state.
I've also fixed up the tests to match the new flow. With the other
additional test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I
think we've narrowed down the main source of test instability that
motivated the startup sequence change.
Added:
Modified:
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/test/API/tools/lldb-dap/breakpoint-events/TestDAP_breakpointEvents.py
lldb/test/API/tools/lldb-dap/cancel/TestDAP_cancel.py
lldb/test/API/tools/lldb-dap/completions/TestDAP_completions.py
lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
lldb/test/API/tools/lldb-dap/console/TestDAP_redirection_to_console.py
lldb/test/API/tools/lldb-dap/coreFile/TestDAP_coreFile.py
lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
lldb/test/API/tools/lldb-dap/module-event/TestDAP_module_event.py
lldb/test/API/tools/lldb-dap/module/TestDAP_module.py
lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
lldb/test/API/tools/lldb-dap/restart/TestDAP_restart.py
lldb/test/API/tools/lldb-dap/send-event/TestDAP_sendEvent.py
lldb/test/API/tools/lldb-dap/stackTrace/TestDAP_stackTrace.py
lldb/test/API/tools/lldb-dap/stackTraceDisassemblyDisplay/TestDAP_stackTraceDisassemblyDisplay.py
lldb/test/API/tools/lldb-dap/startDebugging/TestDAP_startDebugging.py
lldb/test/API/tools/lldb-dap/stop-hooks/TestDAP_stop_hooks.py
lldb/test/API/tools/lldb-dap/threads/TestDAP_threads.py
lldb/test/API/tools/lldb-dap/variables/children/TestDAP_variables_children.py
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
lldb/tools/lldb-dap/Handler/ConfigurationDoneRequestHandler.cpp
lldb/tools/lldb-dap/Handler/InitializeRequestHandler.cpp
lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp
lldb/tools/lldb-dap/Handler/RequestHandler.h
lldb/tools/lldb-dap/Protocol/ProtocolBase.h
lldb/tools/lldb-dap/Protocol/ProtocolRequests.h
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index d3589e78b6bc7..70fd0b0c419db 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -133,6 +133,7 @@ def __init__(
self.output_condition = threading.Condition()
self.output: dict[str, list[str]] = {}
self.configuration_done_sent = False
+self.initialized = False
self.frame_scopes = {}
self.init_commands = init_commands
self.disassembled_instructions = {}
@@ -235,6 +236,8 @@ def _handle_recv_packet(self, packet:
Optional[ProtocolMessage]) -> bool:
self.output_condition.release()
# no need to add 'output' event packets to our packets list
return keepGoing
+elif event == "initialized":
+self.initialized = True
elif event == "process":
# When a new process is attached or launched, remember the
# details that are available in the body of the event
@@ -602,7 +605,7 @@ def request_attach(
exitCommands: Optional[list[str]] = None,
terminateCommands: Optional[list[str]] = None,
coreFile: Optional[
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/ashgti closed https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
JDevlieghere wrote: I took a look at the code and I think the approach looks good. I wonder if there's an opportunity to make this slightly more generic to avoid (1) having to change the interface (i.e. keep returning an `llvm::Error`) and (2) defer the error response so there's no divergence between when we send a success and failure response. That would require doing the checking of the async condition (for async requests) as well as executing the callback (if we don't yet have an error) at the layer above it. I don't know how much that complicates things or if that's worth it (do we expect to use this anywhere else?) in which case feel free to ignore this. https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Avoid creating temporary instances of std::string (NFC) (PR #140325)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/140325 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
ashgti wrote: @da-viper I think this version may be a bit cleaner for https://github.com/llvm/llvm-project/issues/140154, let me know if that works for you https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
https://github.com/JDevlieghere approved this pull request. I think you can move this out of draft. I'm thoroughly convinced that my first stab at this is wrong. The code LGTM and I like that we don't have to launch everything with `stopOnEntry`. The only thing I don't like is that the configurationDone is now once again implicit. In a future PR, I'd love to move the tests to a model where we specify that explicitly after doing the breakpoints (and automatically catch cases where someone forgets, like your PR from earlier this week). I'm happy to sign myself up to do that work. https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update python.rst (PR #140333)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/140333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 9178a17 - Update python.rst (#140333)
Author: LauraElanorJones Date: 2025-05-16T19:17:03-07:00 New Revision: 9178a1720667807aa46dcfc3069bad7e8fef5f2e URL: https://github.com/llvm/llvm-project/commit/9178a1720667807aa46dcfc3069bad7e8fef5f2e DIFF: https://github.com/llvm/llvm-project/commit/9178a1720667807aa46dcfc3069bad7e8fef5f2e.diff LOG: Update python.rst (#140333) Fix code block formatting in section "The Decision Point Breakpoint Commands" Added: Modified: lldb/docs/use/python.rst Removed: diff --git a/lldb/docs/use/python.rst b/lldb/docs/use/python.rst index d9c29d95708c1..3a919f2a8cdb1 100644 --- a/lldb/docs/use/python.rst +++ b/lldb/docs/use/python.rst @@ -330,9 +330,12 @@ decision to go right: process.Continue() else: print "Here is the problem; going right, should go left!" - Just as a reminder, LLDB is going to take this script and wrap it up in a function, like this: +Just as a reminder, LLDB is going to take this script and wrap it up in a function, like this: + +:: + def some_unique_and_obscure_function_name (frame, bp_loc): global path if path[0] == 'R': ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Take two at refactoring the startup sequence. (PR #140331)
JDevlieghere wrote: > Looks like all the tests are passing on linux and for me locally on macOS as > well. All the macOS tests are passing for me as well. https://github.com/llvm/llvm-project/pull/140331 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update python.rst (PR #140333)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/140333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)
https://github.com/ashgti closed https://github.com/llvm/llvm-project/pull/140299 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Listen for broadcast classes. (PR #140142)
ashgti wrote: #140331 will also fix this underlying issue. I think its a better approach to fix this without having to listen for all events. https://github.com/llvm/llvm-project/pull/140142 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] dfac044 - [lldb-dap] Avoid creating temporary instances of std::string (NFC) (#140325)
Author: Kazu Hirata
Date: 2025-05-16T20:02:13-07:00
New Revision: dfac0445d0813abe2260ffdc9eeb23671cefd812
URL:
https://github.com/llvm/llvm-project/commit/dfac0445d0813abe2260ffdc9eeb23671cefd812
DIFF:
https://github.com/llvm/llvm-project/commit/dfac0445d0813abe2260ffdc9eeb23671cefd812.diff
LOG: [lldb-dap] Avoid creating temporary instances of std::string (NFC)
(#140325)
EmplaceSafeString accepts StringRef for the last parameter, str, and
then internally creates a copy of str via StringRef::str or
llvm::json::fixUTF8, so caller do not need to create their own
temporary instances of std::string.
Added:
Modified:
lldb/tools/lldb-dap/EventHelper.cpp
lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
lldb/tools/lldb-dap/JSONUtils.cpp
Removed:
diff --git a/lldb/tools/lldb-dap/EventHelper.cpp
b/lldb/tools/lldb-dap/EventHelper.cpp
index ed2d8700c26b0..c698084836e2f 100644
--- a/lldb/tools/lldb-dap/EventHelper.cpp
+++ b/lldb/tools/lldb-dap/EventHelper.cpp
@@ -93,7 +93,7 @@ void SendProcessEvent(DAP &dap, LaunchMethod launch_method) {
exe_fspec.GetPath(exe_path, sizeof(exe_path));
llvm::json::Object event(CreateEventObject("process"));
llvm::json::Object body;
- EmplaceSafeString(body, "name", std::string(exe_path));
+ EmplaceSafeString(body, "name", exe_path);
const auto pid = dap.target.GetProcess().GetProcessID();
body.try_emplace("systemProcessId", (int64_t)pid);
body.try_emplace("isLocalProcess", true);
diff --git a/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
index 5ce133c33b7e1..e1556846dff19 100644
--- a/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/EvaluateRequestHandler.cpp
@@ -205,7 +205,7 @@ void EvaluateRequestHandler::operator()(
lldb::SBError error = value.GetError();
const char *error_cstr = error.GetCString();
if (error_cstr && error_cstr[0])
-EmplaceSafeString(response, "message", std::string(error_cstr));
+EmplaceSafeString(response, "message", error_cstr);
else
EmplaceSafeString(response, "message", "evaluate failed");
} else {
diff --git a/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
b/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
index 924ea63ed1593..c1c2adb32a510 100644
--- a/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/ExceptionInfoRequestHandler.cpp
@@ -136,7 +136,7 @@ void ExceptionInfoRequestHandler::operator()(
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
-EmplaceSafeString(body, "description", std::string(description));
+EmplaceSafeString(body, "description", description);
}
}
body.try_emplace("breakMode", "always");
diff --git a/lldb/tools/lldb-dap/JSONUtils.cpp
b/lldb/tools/lldb-dap/JSONUtils.cpp
index a8bd672583a5d..714947a4d3b9c 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -905,7 +905,7 @@ llvm::json::Value CreateThreadStopped(DAP &dap,
lldb::SBThread &thread,
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
- EmplaceSafeString(body, "description", std::string(description));
+ EmplaceSafeString(body, "description", description);
}
}
// "threadCausedFocus" is used in tests to validate breaking behavior.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Avoid creating temporary instances of std::string (NFC) (PR #140325)
https://github.com/kazutakahirata closed https://github.com/llvm/llvm-project/pull/140325 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update python.rst (PR #140333)
github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using `@` followed by their GitHub username. If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the [LLVM GitHub User Guide](https://llvm.org/docs/GitHub.html). You can also ask questions in a comment on this PR, on the [LLVM Discord](https://discord.com/invite/xS7Z362) or on the [forums](https://discourse.llvm.org/). https://github.com/llvm/llvm-project/pull/140333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use llvm::replace (NFC) (PR #140343)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Kazu Hirata (kazutakahirata)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/140343.diff
6 Files Affected:
- (modified) lldb/source/Interpreter/CommandInterpreter.cpp (+2-2)
- (modified)
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp (+2-2)
- (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp (+3-6)
- (modified) lldb/source/Utility/FileSpec.cpp (+2-2)
- (modified) lldb/utils/TableGen/LLDBOptionDefEmitter.cpp (+1-1)
- (modified) lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp (+2-2)
``diff
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp
b/lldb/source/Interpreter/CommandInterpreter.cpp
index eb4741feb0aa5..34749d890bf03 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -3346,9 +3346,9 @@ bool CommandInterpreter::SaveTranscript(
CommandReturnObject &result, std::optional output_file) {
if (output_file == std::nullopt || output_file->empty()) {
std::string now = llvm::to_string(std::chrono::system_clock::now());
-std::replace(now.begin(), now.end(), ' ', '_');
+llvm::replace(now, ' ', '_');
// Can't have file name with colons on Windows
-std::replace(now.begin(), now.end(), ':', '-');
+llvm::replace(now, ':', '-');
const std::string file_name = "lldb_session_" + now + ".log";
FileSpec save_location = GetSaveSessionDirectory();
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
index 3b601726388d6..1feeeb64aa9e5 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
@@ -251,8 +251,8 @@ TokenVerifier::TokenVerifier(std::string body) {
// We only care about tokens and not their original source locations. If we
// move the whole expression to only be in one line we can simplify the
// following code that extracts the token contents.
- std::replace(body.begin(), body.end(), '\n', ' ');
- std::replace(body.begin(), body.end(), '\r', ' ');
+ llvm::replace(body, '\n', ' ');
+ llvm::replace(body, '\r', ' ');
FileSystemOptions file_opts;
FileManager file_mgr(file_opts,
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index 3c3a0aa992d9c..262a7dc731713 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -237,12 +237,9 @@ FileSpecList
PlatformDarwin::LocateExecutableScriptingResources(
// ScriptInterpreter. For now, we just replace dots with
// underscores, but if we ever support anything other than
// Python we will need to rework this
- std::replace(module_basename.begin(), module_basename.end(), '.',
- '_');
- std::replace(module_basename.begin(), module_basename.end(), ' ',
- '_');
- std::replace(module_basename.begin(), module_basename.end(), '-',
- '_');
+ llvm::replace(module_basename, '.', '_');
+ llvm::replace(module_basename, ' ', '_');
+ llvm::replace(module_basename, '-', '_');
ScriptInterpreter *script_interpreter =
target->GetDebugger().GetScriptInterpreter();
if (script_interpreter &&
diff --git a/lldb/source/Utility/FileSpec.cpp b/lldb/source/Utility/FileSpec.cpp
index bb2b8647342b8..69d921643da2a 100644
--- a/lldb/source/Utility/FileSpec.cpp
+++ b/lldb/source/Utility/FileSpec.cpp
@@ -60,7 +60,7 @@ void Denormalize(llvm::SmallVectorImpl &path,
FileSpec::Style style) {
if (PathStyleIsPosix(style))
return;
- std::replace(path.begin(), path.end(), '/', '\\');
+ llvm::replace(path, '/', '\\');
}
} // end anonymous namespace
@@ -186,7 +186,7 @@ void FileSpec::SetFile(llvm::StringRef pathname, Style
style) {
// Normalize back slashes to forward slashes
if (m_style == Style::windows)
-std::replace(resolved.begin(), resolved.end(), '\\', '/');
+llvm::replace(resolved, '\\', '/');
if (resolved.empty()) {
// If we have no path after normalization set the path to the current
diff --git a/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
b/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
index 735489c0e56a4..2507910d8a97a 100644
--- a/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
+++ b/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
@@ -150,7 +150,7 @@ static void emitOptions(std::string Command, ArrayRef Records,
std::vector Options(Records.begin(), Records.end());
std::string ID = Command;
- std::replace(ID.begin(), ID.end(), ' ', '_');
+ llvm::replace(ID, ' ', '_');
// Genera
[Lldb-commits] [lldb] [lldb] Use llvm::replace (NFC) (PR #140343)
https://github.com/kazutakahirata created
https://github.com/llvm/llvm-project/pull/140343
None
>From e0f9312651d1e884547bf44b44dd2c6b8ff09ff6 Mon Sep 17 00:00:00 2001
From: Kazu Hirata
Date: Fri, 16 May 2025 20:07:05 -0700
Subject: [PATCH] [lldb] Use llvm::replace (NFC)
---
lldb/source/Interpreter/CommandInterpreter.cpp | 4 ++--
.../ExpressionParser/Clang/ClangExpressionSourceCode.cpp | 4 ++--
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | 9 +++--
lldb/source/Utility/FileSpec.cpp | 4 ++--
lldb/utils/TableGen/LLDBOptionDefEmitter.cpp | 2 +-
lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp | 4 ++--
6 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp
b/lldb/source/Interpreter/CommandInterpreter.cpp
index eb4741feb0aa5..34749d890bf03 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -3346,9 +3346,9 @@ bool CommandInterpreter::SaveTranscript(
CommandReturnObject &result, std::optional output_file) {
if (output_file == std::nullopt || output_file->empty()) {
std::string now = llvm::to_string(std::chrono::system_clock::now());
-std::replace(now.begin(), now.end(), ' ', '_');
+llvm::replace(now, ' ', '_');
// Can't have file name with colons on Windows
-std::replace(now.begin(), now.end(), ':', '-');
+llvm::replace(now, ':', '-');
const std::string file_name = "lldb_session_" + now + ".log";
FileSpec save_location = GetSaveSessionDirectory();
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
index 3b601726388d6..1feeeb64aa9e5 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
@@ -251,8 +251,8 @@ TokenVerifier::TokenVerifier(std::string body) {
// We only care about tokens and not their original source locations. If we
// move the whole expression to only be in one line we can simplify the
// following code that extracts the token contents.
- std::replace(body.begin(), body.end(), '\n', ' ');
- std::replace(body.begin(), body.end(), '\r', ' ');
+ llvm::replace(body, '\n', ' ');
+ llvm::replace(body, '\r', ' ');
FileSystemOptions file_opts;
FileManager file_mgr(file_opts,
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index 3c3a0aa992d9c..262a7dc731713 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -237,12 +237,9 @@ FileSpecList
PlatformDarwin::LocateExecutableScriptingResources(
// ScriptInterpreter. For now, we just replace dots with
// underscores, but if we ever support anything other than
// Python we will need to rework this
- std::replace(module_basename.begin(), module_basename.end(), '.',
- '_');
- std::replace(module_basename.begin(), module_basename.end(), ' ',
- '_');
- std::replace(module_basename.begin(), module_basename.end(), '-',
- '_');
+ llvm::replace(module_basename, '.', '_');
+ llvm::replace(module_basename, ' ', '_');
+ llvm::replace(module_basename, '-', '_');
ScriptInterpreter *script_interpreter =
target->GetDebugger().GetScriptInterpreter();
if (script_interpreter &&
diff --git a/lldb/source/Utility/FileSpec.cpp b/lldb/source/Utility/FileSpec.cpp
index bb2b8647342b8..69d921643da2a 100644
--- a/lldb/source/Utility/FileSpec.cpp
+++ b/lldb/source/Utility/FileSpec.cpp
@@ -60,7 +60,7 @@ void Denormalize(llvm::SmallVectorImpl &path,
FileSpec::Style style) {
if (PathStyleIsPosix(style))
return;
- std::replace(path.begin(), path.end(), '/', '\\');
+ llvm::replace(path, '/', '\\');
}
} // end anonymous namespace
@@ -186,7 +186,7 @@ void FileSpec::SetFile(llvm::StringRef pathname, Style
style) {
// Normalize back slashes to forward slashes
if (m_style == Style::windows)
-std::replace(resolved.begin(), resolved.end(), '\\', '/');
+llvm::replace(resolved, '\\', '/');
if (resolved.empty()) {
// If we have no path after normalization set the path to the current
diff --git a/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
b/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
index 735489c0e56a4..2507910d8a97a 100644
--- a/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
+++ b/lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
@@ -150,7 +150,7 @@ static void emitOptions(std::string Command, ArrayRef Records,
std::vector Options(Records.begin(), Records.end());
std::strin
