jimingham wrote: A couple of comments on Jonas' comments. First, I don't think it's necessary to have a privileged "real stack frame list" and the a "scripted stack frame provider" that refers to it. There's no reason this can't be a chain of providers. The important thing is that each provider is given the stackframelist it uses as its source material that it asks when it needs more frames to work on. It shouldn't need to know where those stack frames are coming from.
Also, I agree the StackFrameList providers should be held by the target because among other things users need to set them so they are available the first time a new process stops, which is straightforward if the target holds them. OTOH, I do think that there should be some "AppropriateForThread" API in the provider. If you know that all the threads you are going to work on have a particular thread name or belong to a specific queue or whatever, there should be a way to express that so the we don't end up asking the providers to do a bunch of useless work. https://github.com/llvm/llvm-project/pull/161870 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
