[libcxx-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[via libcxx-commits]

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