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

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang commented:

Being able to filter the frame list would be amazing - thansk for looking into this! 🙂 

As it happens, I am currently looking into gdb's "frame filter" API, which serves a very similar use case - and I am wondering if we should take some inspiration from the gdb APIs here.

In particular, the gdb frame filter API provides the following benefits which we might also want to have in LLDB:

* **simpler API**: gdb's API only has a single function `filter(frame_iter) -> frame_iter` function. (This PR currently introduces two functions: `get_merge_strategy` and `get_stack_frames`)
* **lazy stack unwinding**: afaict, your patch leads to eager materialization of all stack frames. Given that stacks can be pretty deep, it would be preferable to only create those stack frames lazily, as the users inspects the stack. gdb achieves this by only advancing the returned iterator as needed
* **more flexible merging strategies**: in gdb, I can use all of Python's iterator support (generator expressions, `yield`, ...)
* **global registration**: in gdb, frame filters are registered globally for all threads. In this PR, the frame providers are registered for each thread individually
* **multiple frame filters**: gdb supports registering multiple frame filters at the same time. I didn't use that mechanism, yet, but afaict they are simply chained

The relevant pieces of gdb's documentation:
* [Writing a frame filter](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Writing-a-Frame-Filter.html) - high-level introduction
* [Frame filter API](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Frame-Filter-API.html) - corresponding API reference
* [Frame decorators API](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Frame-Decorator-API.html#Frame-Decorator-API) - close equivalent to lldb's `ScriptedFrame`
* [Frame filter management](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Frame-Filter-Management.html#Frame-Filter-Management) - end users can change enable, disable and reorder frame filters

My motivation for using frame filters in gdb are C++ couroutines. I want to add frames for asynchronous operations. For more background see LLVM's documentatin on [Async Stack Traces](https://clang.llvm.org/docs/DebuggingCoroutines.html#async-stack-traces), in particular the `coro bt` example. At least for my use case, gdb's design decisions (global registration, flexible merging strategy, ...) are a pretty good fit. But not sure, maybe your current design is a better fit for your particular use case? Which use case are you envisioning?

By the way: would discourse be better-suited for discussing the best approach here? Happy to copy my reply over to discourse, if you would start a thread

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