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

[Robert O'Callahan via lldb-commits]

rocallahan wrote:

> > @clayborg as far as I can tell, the ball is currently in your court to respond to @jimingham ... thanks in advance
> 
> Sounds like Jim is on the fence with a SetDirection + existing APIs and adding a direction to the calls. I am fine with either approach as long as Jim is ok with it because Jim is the code owner of the thread plans so he has better knowledge. Let me know if I missed any comment I should respond to other than this.

The initial disagreement here was that you advocated for a `ReverseContinue()` function (etc) while Jim didn't want to add `Reverse` versions of functions. It sounds like you're on board with the latter now, so thanks for that.

So now the question is whether to expose a persistent "current direction" flag or pass the direction as a parameter (defaulting to "forward") to each call to a function that advances execution.

> It really comes down to how the GUI and command line commands work for reverse debugging. So a few questions:
> 
>     * Do GUI debuggers have different buttons for reverse stepping and running? Or is there a direction button and then the existing process control buttons remain the same (reverse continue, reverse step in/out/over)

I've only seen them use separate buttons, see e.g. [CLion + UndoDB](https://blog.jetbrains.com/clion/2016/09/undo-for-clion/).

>     * For command line do we have different comments for forward and reverse, or a direction command followed by normal commands?

GDB [supports both](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html). However, in practice I've never seen anyone use `set exec-direction`. My LLDB CLI patch adds a `-R` option to `thread continue`.

> If the GUI and command line have separate buttons and commands, then we should probably go with adding the direction to each API.

OK, then I believe my current code is satisfactory.

> I could see us adding more options to the `SBThreadStepOptions` API in the future and then our public API for `SBThread::StepOver` doesn't need to change.

Sure. My current code doesn't support reverse stepping and the number of options to the `Continue()` APIs is small (zero currently for `SBProcess::Continue()`) so this isn't an issue yet.

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