jimingham wrote: There are two clients for stack unwinding in general, with different performance needs. There's the users of the `bt` command or it's SB API equivalents who are operating on human timescales, and there's the execution control machinery, which gets invoked much more frequently in an algorithmic fashion.
For execution control, we need to be careful never to unwind more frames than needed, since you stop a lot to go from place to place, the turnaround time is important to keeping stepping lively. I don't think we want to introduce unbounded frame unwinding to the execution control stops. However, with these new "hiding frame" recognizers, we are using the frame hiding recognizers to handle "step out past hidden frames". So if - as was done in the original implementation - we're determining this during execution control, its hard to see how we can avoid running these recognizers all the time. That argues for not allowing unbounded backtracing in recognizers. Another way to do this would be to make the "step out past hidden frames" be something we calculate when you issue the "step out" command. step-out already has a settable "step-out-to frame" parameter. So if you stopped "to the user" and then they said "step out" - at that point it would be fine to run the recognizer (you probably already have) and then directly issue "step out to frame <the one before the hidden frames>". That would save the execution control machinery from having to do this. I don't have a detailed plan for this, but I think given the kinds of ambitions people seem likely to have for the recognizers, we need to separate these two use cases. We should add a distinction to the stack backtracking machinery between "partial stack requests from the execution control" and "full stack requests from users". The former should never do extra work for the recognizers, whereas the latter can trade off speed for richer information. I don't think that would be all that hard to do. One somewhat ham-fisted way to do it is only run the recognizers if someone asks for N frames, and we find the full stack is less than N, then run the recognizers. The execution control machinery never asks for more than a couple of frames... OTOH, a well done GUI might only ask for as many frames as it was going to display, which this way wouldn't serve. So it would be better to make this an explicit gesture somehow. Jim > On Sep 24, 2024, at 12:36 AM, Adrian Vogelsgesang ***@***.***> wrote: > > > This is why I said on the bug that it would be better to match one of the > public symbols higher up the stack. How to best to that is the open question > > Is the following correct: Even if the user does not have debug symbols > installed, it would always be sufficient to match the first named framed. > > If so, we could change StackFrameList::SelectMostRelevantFrame to match > against the first frame which has a name available. Although, that might > already cause a lot of unwinding, in case no debug info is available at all... > > — > Reply to this email directly, view it on GitHub > <https://github.com/llvm/llvm-project/pull/109594#issuecomment-2370428841>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADUPVW5XSQRRU34K5RRHLNLZYEJANAVCNFSM6AAAAABOU6Y2KKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZQGQZDQOBUGE>. > You are receiving this because you were mentioned. > https://github.com/llvm/llvm-project/pull/109594 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
