================ @@ -0,0 +1,149 @@ +import lldb +import time +import unittest +from lldbsuite.test.lldbtest import * +from lldbsuite.test.decorators import * +from lldbsuite.test.gdbclientutils import * +from lldbsuite.test.lldbreverse import ReverseTestBase +from lldbsuite.test import lldbutil + + +class TestReverseContinueBreakpoints(ReverseTestBase): + def test_reverse_continue(self): + self.reverse_continue_internal(async_mode=False) + + def test_reverse_continue_async(self): + self.reverse_continue_internal(async_mode=True) + + def reverse_continue_internal(self, async_mode): + target, process, initial_threads = self.setup_recording(async_mode) + + # Reverse-continue. We'll stop at the point where we started recording. + status = process.ContinueInDirection(lldb.eRunReverse) + self.assertSuccess(status) + self.expect_async_state_changes( + async_mode, process, [lldb.eStateRunning, lldb.eStateStopped] + ) + self.expect( + "thread list", + STOPPED_DUE_TO_HISTORY_BOUNDARY, + substrs=["stopped", "stop reason = history boundary"], + ) ---------------- rocallahan wrote:
Yes, good point. The PC should point to the instruction that modifies the watched variable. We can't test that directly since it's hard to figure out where that instruction is, but we can singlestep one instruction forward and verify that the variable value changes. So I've added that. https://github.com/llvm/llvm-project/pull/112079 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
