vogelsgesang wrote: @jimingham > I don't see why you say "I don't have a way to store state between > get_stack_frames calls".
I misinterpreted the code in review and thought we would create a new instance on every call > I kind of like the latter approach ["will_resume" and maybe "did_stop" > callback] better because it might be useful for the provider to remember what > it had produced the last time round. đ I agree, the callbacks would be nicer. E.g., for C++ coroutines, that will allow me to cache the common frames further up the stack which only change infrequently. > Also, at base, in Python `some_thread.GetFrameAtIndex(5)` has got to work to > produce whatever the current view of that thread's stack frame list wants to > present for that frame. We could still provide `some_thread.GetFrameAtIndex(5)` by internally (in lldb) advancing the generator until we have 5 stack frames available. > It seems easier to treat that as the primitive and wrap a generator approach > around that if you like it better. Easier for whom? lldb developers or for the users of this extension point or both? At least to me, it seems simpler to write a generator in Python, while I agree that the code required in LLDB to support generators would be more / harder. Afaict, there will never be a way to produce stack frame 5 without also producing stack frame 1 - 4. As such, a generator feels more natural. Or am I missing something? Are there any architectures / stack layouts / ... out there where I could directly access stack frame 5? https://github.com/llvm/llvm-project/pull/161870 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
