[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[Robert O'Callahan via lldb-commits]

================
@@ -1363,6 +1374,43 @@ Status ProcessGDBRemote::DoResume() {
       }
     }
 
+    if (direction == RunDirection::eRunReverse && continue_packet_error) {
+      if (num_continue_C_tids > 0 || num_continue_S_tids > 0) {
+        error.SetErrorString("can't deliver signals while running in reverse");
+        LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: Signals not supported");
+        return error;
+      }
+
+      if (num_continue_s_tids > 0) {
+        if (num_continue_s_tids > 1) {
+          error.SetErrorString("can't step multiple threads while reverse-stepping");
+          LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: can't step multiple threads");
+          return error;
+        }
+
+        if (!m_gdb_comm.GetReverseStepSupported()) {
+          error.SetErrorString("target does not support reverse-stepping");
+          LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: target does not support reverse-stepping");
+          return error;
+        }
+
+        m_gdb_comm.SetCurrentThreadForRun(m_continue_s_tids.front());
+        continue_packet.PutCString("bs");
+      } else {
+        if (!m_gdb_comm.GetReverseContinueSupported()) {
----------------
rocallahan wrote:

We need to determine whether we're going to step or continue first, so we can check whether the specific packet (`bs` or `bc`) we need is supported. I suppose we could collapse them into one feature flag and check that flag a bit earlier --- that would work fine in practice --- but I think what I have here, with a feature flag check right where we use that exact feature,  is a little more intuitive. I think the priority here should be the simplest, clearest code; "user tries to reverse-continue but that's not supported" is not a case that needs to be optimized.

https://github.com/llvm/llvm-project/pull/99736