[lldb] Set the stop reason when receiving swbreak/hwbreak #108518
Conversation
xusheng added support for swbreak/hwbreak a month ago, and no special support was needed in ProcessGDBRemote when they're received because lldb already marks a thread as having hit a breakpoint when it stops at a breakpoint site. However, with changes I am working on, we need to know the real stop reason a thread stopped or the breakpoint hit will not be recognized. This is similar to how lldb processes the "watch/rwatch/awatch" keys in a thread stop packet -- we set the `reason` to `watchpoint`, and these set it to `breakpoint` so we set the stop reason correctly later in these methods.
|
@llvm/pr-subscribers-lldb Author: Jason Molenda (jasonmolenda) Changesxusheng added support for swbreak/hwbreak a month ago, and no special support was needed in ProcessGDBRemote when they're received because lldb already marks a thread as having hit a breakpoint when it stops at a breakpoint site. However, with changes I am working on, we need to know the real stop reason a thread stopped or the breakpoint hit will not be recognized. This is similar to how lldb processes the "watch/rwatch/awatch" keys in a thread stop packet -- we set the Full diff: https://github.com/llvm/llvm-project/pull/108518.diff 1 Files Affected:
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 5eaf9ce2a302aa..271ff61a7188a6 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2317,6 +2317,8 @@ StateType ProcessGDBRemote::SetThreadStopInfo(StringExtractor &stop_packet) {
StreamString ostr;
ostr.Printf("%" PRIu64, wp_addr);
description = std::string(ostr.GetString());
+ } else if (key.compare("swbreak") == 0 || key.compare("hwbreak") == 0) {
+ reason = "breakpoint";
} else if (key.compare("library") == 0) {
auto error = LoadModules();
if (error) {
|
|
This is the follow up patch I alluded to in #102873 needed for my work to re-land my change to how breakpoints are handled in lldb (work in progress at #108504 ). It's the same thing we do for watchpoints just above this point, setting the |
Breaking this patch out into a separate PR llvm#108518 This reverts commit 3408ce1.
There was a problem hiding this comment.
Still curious exactly how we end up with threads on a breakpoint that didn't execute it - #108504 (comment)
But aside from that this LGTM.
xusheng added support for swbreak/hwbreak a month ago, and no special support was needed in ProcessGDBRemote when they're received because lldb already marks a thread as having hit a breakpoint when it stops at a breakpoint site. However, with changes I am working on, we need to know the real stop reason a thread stopped or the breakpoint hit will not be recognized. This is similar to how lldb processes the "watch/rwatch/awatch" keys in a thread stop packet -- we set the `reason` to `watchpoint`, and these set it to `breakpoint` so we set the stop reason correctly later in these methods. (cherry picked from commit 65a4d11)
xusheng added support for swbreak/hwbreak a month ago, and no special support was needed in ProcessGDBRemote when they're received because lldb already marks a thread as having hit a breakpoint when it stops at a breakpoint site. However, with changes I am working on, we need to know the real stop reason a thread stopped or the breakpoint hit will not be recognized. This is similar to how lldb processes the "watch/rwatch/awatch" keys in a thread stop packet -- we set the `reason` to `watchpoint`, and these set it to `breakpoint` so we set the stop reason correctly later in these methods. (cherry picked from commit 65a4d11)
xusheng added support for swbreak/hwbreak a month ago, and no special support was needed in ProcessGDBRemote when they're received because lldb already marks a thread as having hit a breakpoint when it stops at a breakpoint site. However, with changes I am working on, we need to know the real stop reason a thread stopped or the breakpoint hit will not be recognized. This is similar to how lldb processes the "watch/rwatch/awatch" keys in a thread stop packet -- we set the `reason` to `watchpoint`, and these set it to `breakpoint` so we set the stop reason correctly later in these methods. (cherry picked from commit 65a4d11)
xusheng added support for swbreak/hwbreak a month ago, and no special support was needed in ProcessGDBRemote when they're received because lldb already marks a thread as having hit a breakpoint when it stops at a breakpoint site. However, with changes I am working on, we need to know the real stop reason a thread stopped or the breakpoint hit will not be recognized.
This is similar to how lldb processes the "watch/rwatch/awatch" keys in a thread stop packet -- we set the
reasontowatchpoint, and these set it tobreakpointso we set the stop reason correctly later in these methods.