rocallahan wrote: > Most of the execution control logic should just know "forward" and > "backwards", but then whether those are implemented by using the reverse > debugging machinery or by allowing the program to run for realz will be know > deeper in the execution control machinery - most likely governed by the > thread plans.
Actually LLDB is (and should be) oblivious to whether the gdbserver is running the program "for realz" or not. When using rr, we currently *never* run the program "for realz" while the user is in a debugging session. The workflow is: a) record a program run and save the recording to disk b) replay the run with the debugger attached. During b), both forward and reverse execution are "on rails", only observing what happened during recording. (Ok, ignoring user-requested function calls made through the debugger for now.) UndoDB and gdb's reverse execution are a bit different. They do support the workflow you're thinking of, where the program is actually "live" while you explore history in the past. But the distinction between "replaying through history" and "runinng live" is never surfaced in the gdbserver protocol and from the debugger's point of view I don't think it should matter. https://github.com/llvm/llvm-project/pull/99736 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
