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

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

Thanks for making the frame iteration lazy!

> let me know if this newer approach fits better into your coroutines workflow.

**Lazy stack unwinding**

Unfortunately, I don't think that `SBFrameList` as currently in review is sufficient. The input parameter to `get_stack_frames` now allows me to lazily iterate over the input stack frames. But the result type of `get_stack_frames` is still `List[Dict]`, i.e. I still have to generate all artificial frames in one go. Even if the user only displays the first 20 stack frames, for deep stacks I have to synthesize 100s or 1000s of `Dict` entries which the user will never see.

**Merging strategy**

None of the provided merging strategies (replace, prepend, append, replace-by-index) matches the need for coroutine stack traces. I need to splice in additional stack frames in the middle of real, physical stack frames.

I still think that the best, most future proof solution here would be to delegate the merging strategy to the script.

I.e. have the interface be `get_stack_frames(Iterable[SBFrame]) -> Iterable[SBFrame]`, where `SBFrame` might be either a forwarded physical frame or an artificial `ScriptedFrame`. I guess `ScriptedFrame` should inherit from `SBFrame`? Or there should be a `SBFrame.FromScriptedFrame` factory function? Or something similar? In case none of this is possible, we could use `get_stack_frames(Iterable[SBFrame]) -> Iterable[SBFrame | Dict | ScriptedFrame]` or some similar signature

**Registration**

At least for my use case, I would like to globally register the frame filter for all threads.
The frame provider would then inspect the stack frames and see if any C++ coroutines were used. If so, it would inject the additional threads.
The end user wouldn't need to register the frame provider for individual threads, and things would just work "out of the box".

### CPython Use Case

I think that at least "Lazy stack unwinding" and "Registration" would also be issues for your CPython use case.

You probably don't want to eagerly unwind the full stack to identify which frames to replace (afaik, the CPython frames could be arbitrarily far up in the call stack and you wouldn't have a way to terminate the stack traversal in `get_stack_frames` early?). As such, also your script could benefit from lazy unwinding?

Furthermore, it would probably also be more convenient for your users if your script automatically becomes active for all relevant CPython frames on all threads, without the user having associate individual threads with your frame provider?

But maybe I am still misunderstanding your use case? Can you share your CPython frame provider script?

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