jimingham wrote: > > When we were talking about this originally I thought that StackFrames would > > get an "ImplementationFrame" property, and we would use that to determine > > whether to hide the frame in bt (when not passing --unfiltered). Then the > > frame recognizers when they are run on the frame in the ordinary course of > > things (we do this to determine recognized args anyway) they would set the > > property on the StackFrame. Then StackFrameList could just check that > > property. RecognizeFrame might be expensive, and we don't currently have > > any machinery in place to make sure it caches the results per stop. Most of > > the RecognizeFrame's just do the work every time. I also think for > > structural reasons we shouldn't force FrameRecognizers to be the only > > entity that can mark frames as "should be hidden." > > I understand that not recomputing them might be desirable, but this is not > how recognizers currently work. The only place frame recognizers currently > get called is by `Thread::GetStopDescription()` (for frame #0) and by > `Thread::GetCurrentException()` (also frame #0). So it's not true that we are > computing them anyway and thus have an opportunity to precompute the isHidden > attribute. I also think that from an architectural perspective it would be > wrong for a frame recognizer to be allowed to modify the state of a > StackFrame.
This is entirely tangential to this patch, which looks fine to me, but one of the jobs of a Frame recognizer is to add arguments to a StackFrame that doesn't have them. That's way more intrusive than just setting a "ShouldHide" type flag... > > When a frame recognizer is registered it takes a module regex a function > regex and a first_instruction flag. All three of these must match before the > recognizer is executed. That's num_recognizers*num_frames regexes. That's not > expensive in the grans scheme of things, but you're right that it's not > necessary. > > I'll see if I can hide the recognizer invocation inside > StackFrame::shouldHide() and let StackFrame cache the result instead of > having the Recognizer modify the StackFrame. Maybe I can come up with some > cache invalidation strategy that makes sense. https://github.com/llvm/llvm-project/pull/104523 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
