jimingham wrote:


> On Sep 23, 2024, at 11:46 AM, Adrian Vogelsgesang ***@***.***> wrote:
> 
> 
> @vogelsgesang commented on this pull request.
> 
> In libcxx/docs/UserDocumentation.rst 
> <https://github.com/llvm/llvm-project/pull/108870#discussion_r1771923035>:
> 
> > +
> +  (lldb) thread backtrace
> +  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
> +    * frame #0: 0x000055555555520e a.out`my_comparator(a=1, b=8) at 
> test-std-sort.cpp:6:3
> +      frame #7: 0x0000555555555615 a.out`void 
> std::__1::sort[abi:ne200000]<std::__1::__wrap_iter<int*>, bool (*)(int, 
> int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) 
> at test-std-sort.cpp:5)) at sort.h:1003:3
> +      frame #8: 0x000055555555531a a.out`main at test-std-sort.cpp:24:3
> +
> +Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking 
> at
> +the frame numbers, we can see that frames #1 until #6 were hidden. Those 
> frames
> +represent internal implementation details such as ``__sort4`` and similar
> +utility functions.
> +
> +To also show those implementation details, use ``thread backtrace -u``.
> +Alternatively, to disable those compact backtraces, use ``frame recognizer 
> list``
> +and ``frame recognizer disable`` on the "libc++ frame recognizer".
> +
> I assume that this mechanism can be disabled via settings set 
> target.process.thread.step-avoid-regexp ""? Or would that match every frame 
> and break stepping completely?
> 
The `thread.step-avoid-regexp` should be independent of this hiding of frames.  
For instance, if I have a bunch of teeny accessors in my library, I might just 
want not to step into them, not because I want to hide them in general, but 
they just make stepping annoying.  That's also an appropriate use of this 
regexp.  Even in the usage for C++ avoidance, I don't think the two are 
overlapping.  After all, std::vector<T>::size isn't an "implementation detail" 
of std in the same way all these shims are, but I still don't want to step into 
it... Anyway, this one belongs to the user so it seems the wrong place to hook 
up this hiding.

It does seem reasonable for both step-in and step-out to avoid "hidden" frames 
by not stopping in them.  IIRC, Adrian's initial patch made step-out step past 
all the hidden frames.  I don't remember seeing anything in that patch that 
makes "step in to hidden frame" turn into step-out but that also seems a 
reasonable behavior.  In both cases, you still run the risk of an over-eager 
hider turning "step-out" into "continue", however.

IMO, the step-avoid-regex & step-avoid-library settings should be independent 
of this hiding feature, and should belong to the user to mess with independent 
of these features.  It also seems pretty reasonable that if you step out to a 
frame we were going to hide, or into a frame that we were going to hide, we 
step you back out.  And I also think it's reasonable that turning off this 
stepping behavior is done by turning off the hiding.  I can't see the need for 
a separate setting for this.

Jim
> —
> Reply to this email directly, view it on GitHub 
> <https://github.com/llvm/llvm-project/pull/108870#discussion_r1771923035>, or 
> unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ADUPVW25DOTCBKLWGEQYCSTZYBOX5AVCNFSM6AAAAABOJ4R5PSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMRTGA2TOMRZGE>.
> You are receiving this because you are on a team that was mentioned.
> 



https://github.com/llvm/llvm-project/pull/108870
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to