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

[Med Ismail Bennani via lldb-commits]

medismailben wrote:

Hello! Thanks for your interest in this PR.

> Being able to modify the frame list from a script would indeed be amazing - thanks 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. Gdb's frame filter API differs from the API in this PR in the following points:
> 

A non-goal for this PR and for lldb in general is copy what gdb or other debuggers do.

> * **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]f(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?
> 

That sounds pretty exciting. I think ScriptedFrameProvider would be a great fit to support coroutines as long as the ABI doesn't spawn new threads for that. My current use case for this is to translate CPython frames into something that's more understandable, to hopefully improve debugging python / C++ interoperability in lldb.

> 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