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 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
