[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

[via lldb-commits]

jimingham wrote:

And as far as stepping goes - which this PR doesn't really address - we will also need to have an API in the StackFrameList provider like

virtual SBThreadPlan Thread::PerformSteppingOperation(uint64_t stack_index, lldb::eStepType eStepTypeStepOut);

If there was a synthetic StackFrameList, it would decide what next meant to it in this frame, and return a thread plan that makes that happen using either "RunToBreakpoint" thread plans or any of the other primitive types.  

For instance, if I've done my Tcl transmogrification, and I can tell that the state of the Tcl C frames that it is stopped at line 4 of some Tcl source, then I can cons up a thread plan to put a breakpoint on where the implementation code fetches the next source line or break on some "new context" observer function if the language I'm emulating provides that, and then run till that shows a changed source line.

Or maybe step out means finding the Tcl frame that's higher on the C Stack (in Tcl the C & Tcl stacks mirror one another) and just run till we get back to that.  If we have a general mechanism we don't have to know about any of how this works, that's the provider's job.

Then, since the scripted StackFrameList provider always ends at the "natural" stack frame list, when the oldest SyntheticStackFrameList requests PerformSteppingOperation, that will go to the "natural" StackFrameList, whose PerformSteppingOperation will just return the current StepOver, etc thread plans for that thread.

I think this shouldn't be that difficult to implement, and we already have support for writing scripted thread plans so the providers can do pretty much anything execution-control-wise that lldb can do internally.  So this should be pretty flexible.

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