[lldb] Broadcast eBroadcastBitStackChanged when frame providers change#171482
Conversation
|
@llvm/pr-subscribers-lldb Author: Adrian Vogelsgesang (vogelsgesang) ChangesWe want to reload the call stack whenever the frame providers are updated. To do so, we now emit a I found this very useful while iterating on a frame provider in lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the back trace in VS-Code gets refreshed immediately upon running Full diff: https://github.com/llvm/llvm-project/pull/171482.diff 2 Files Affected:
diff --git a/lldb/include/lldb/Target/Target.h b/lldb/include/lldb/Target/Target.h
index 812a638910b3b..6d1f5f83d153b 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -776,6 +776,11 @@ class Target : public std::enable_shared_from_this<Target>,
const llvm::DenseMap<uint32_t, ScriptedFrameProviderDescriptor> &
GetScriptedFrameProviderDescriptors() const;
+protected:
+ /// Notify all threads that the stack traces might have changed.
+ void NotifyThreadsOfChangedFrameProviders();
+
+public:
// This part handles the breakpoints.
BreakpointList &GetBreakpointList(bool internal = false);
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 2305f1019ea4f..fe8e41ec4d825 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -3725,47 +3725,43 @@ llvm::Expected<uint32_t> Target::AddScriptedFrameProviderDescriptor(
if (!descriptor.IsValid())
return llvm::createStringError("invalid frame provider descriptor");
+ uint32_t descriptor_id = descriptor.GetID();
+
llvm::StringRef name = descriptor.GetName();
if (name.empty())
return llvm::createStringError(
"frame provider descriptor has no class name");
- std::lock_guard<std::recursive_mutex> guard(
- m_frame_provider_descriptors_mutex);
-
- uint32_t descriptor_id = descriptor.GetID();
- m_frame_provider_descriptors[descriptor_id] = descriptor;
+ {
+ std::unique_lock<std::recursive_mutex> guard(m_frame_provider_descriptors_mutex);
+ m_frame_provider_descriptors[descriptor_id] = descriptor;
+ }
- // Clear frame providers on existing threads so they reload with new config.
- if (ProcessSP process_sp = GetProcessSP())
- for (ThreadSP thread_sp : process_sp->Threads())
- thread_sp->ClearScriptedFrameProvider();
+ NotifyThreadsOfChangedFrameProviders();
return descriptor_id;
}
bool Target::RemoveScriptedFrameProviderDescriptor(uint32_t id) {
- std::lock_guard<std::recursive_mutex> guard(
- m_frame_provider_descriptors_mutex);
- bool removed = m_frame_provider_descriptors.erase(id);
-
- if (removed)
- if (ProcessSP process_sp = GetProcessSP())
- for (ThreadSP thread_sp : process_sp->Threads())
- thread_sp->ClearScriptedFrameProvider();
+ bool removed;
+ {
+ std::lock_guard<std::recursive_mutex> guard(
+ m_frame_provider_descriptors_mutex);
+ removed = m_frame_provider_descriptors.erase(id);
+ }
+ if (removed) NotifyThreadsOfChangedFrameProviders();
return removed;
}
void Target::ClearScriptedFrameProviderDescriptors() {
- std::lock_guard<std::recursive_mutex> guard(
- m_frame_provider_descriptors_mutex);
-
- m_frame_provider_descriptors.clear();
+ {
+ std::lock_guard<std::recursive_mutex> guard(
+ m_frame_provider_descriptors_mutex);
+ m_frame_provider_descriptors.clear();
+ }
- if (ProcessSP process_sp = GetProcessSP())
- for (ThreadSP thread_sp : process_sp->Threads())
- thread_sp->ClearScriptedFrameProvider();
+ NotifyThreadsOfChangedFrameProviders();
}
const llvm::DenseMap<uint32_t, ScriptedFrameProviderDescriptor> &
@@ -3775,6 +3771,21 @@ Target::GetScriptedFrameProviderDescriptors() const {
return m_frame_provider_descriptors;
}
+void Target::NotifyThreadsOfChangedFrameProviders() {
+ ProcessSP process_sp = GetProcessSP();
+ if (!process_sp)
+ return;
+ for (ThreadSP thread_sp : process_sp->Threads()) {
+ // Clear frame providers on existing threads so they reload with new config.
+ thread_sp->ClearScriptedFrameProvider();
+ // Notify threads that the stack traces might have changed.
+ if (EventTypeHasListeners(Thread::eBroadcastBitStackChanged)) {
+ auto data_sp = std::make_shared<Thread::ThreadEventData>(thread_sp);
+ thread_sp->BroadcastEvent(Thread::eBroadcastBitStackChanged, data_sp);
+ }
+ }
+}
+
void Target::FinalizeFileActions(ProcessLaunchInfo &info) {
Log *log = GetLog(LLDBLog::Process);
|
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
|
This looks fine to me, except that it is a little odd to have a function called |
b42d277 to
9468ba4
Compare
LLM-generated proposals:
Any preference? Otherwise, I would probably go with |
medismailben
left a comment
There was a problem hiding this comment.
LGTM with comments. Please write a test for this to make sure we receive the event as expected.
d4ec168 to
2011d92
Compare
🐧 Linux x64 Test Results
✅ The build succeeded and all tests passed. |
|
ok, AI failed at generating a correct test case. I will need some time to understand how to use SBListeners from Python |
2011d92 to
7dde47e
Compare
We want to reload the call stack whenever the frame providers were updated. To do so, we now emit a `eBroadcastBitStackChanged` on all threads whenever any changes to the frame providers take place. I found this very useful while iterating on a frame provider using lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the back trace in VS-Code gets refreshed immediately upon running `target frame-provider add`
7dde47e to
6e93631
Compare
|
✅ With the latest revision this PR passed the Python code formatter. |
|
/cherry-pick 943782b |
Error: Command failed due to missing milestone. |
|
/cherry-pick 943782b |
|
Failed to cherry-pick: 943782b https://github.com/llvm/llvm-project/actions/runs/21727862504 Please manually backport the fix and push it to your github fork. Once this is done, please create a pull request |
|
Ok, takes some rebasing effort to backport this. |
…nge (llvm#171482) We want to reload the call stack whenever the frame providers are updated. To do so, we now emit a `eBroadcastBitStackChanged` on all threads whenever any changes to the frame providers take place. I found this very useful while iterating on a frame provider in lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the backtrace in VS-Code gets refreshed immediately upon running `target frame-provider add`.
…nge (llvm#171482) We want to reload the call stack whenever the frame providers are updated. To do so, we now emit a `eBroadcastBitStackChanged` on all threads whenever any changes to the frame providers take place. I found this very useful while iterating on a frame provider in lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the backtrace in VS-Code gets refreshed immediately upon running `target frame-provider add`. (cherry picked from commit 943782b)
…nge (llvm#171482) We want to reload the call stack whenever the frame providers are updated. To do so, we now emit a `eBroadcastBitStackChanged` on all threads whenever any changes to the frame providers take place. I found this very useful while iterating on a frame provider in lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the backtrace in VS-Code gets refreshed immediately upon running `target frame-provider add`.
…nge (llvm#171482) We want to reload the call stack whenever the frame providers are updated. To do so, we now emit a `eBroadcastBitStackChanged` on all threads whenever any changes to the frame providers take place. I found this very useful while iterating on a frame provider in lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the backtrace in VS-Code gets refreshed immediately upon running `target frame-provider add`.
We want to reload the call stack whenever the frame providers are updated. To do so, we now emit a
eBroadcastBitStackChangedon all threads whenever any changes to the frame providers take place.I found this very useful while iterating on a frame provider in lldb-dap. So far, the new frame provider only took effect after continuing execution. Now the backtrace in VS-Code gets refreshed immediately upon running
target frame-provider add.