[Lldb-commits] [PATCH] D118814: [lldb] Don't keep demangled names in memory after indexing

Mon Feb 7 00:35:52 PST 2022

labath added a comment.

In D118814#3297198 <https://reviews.llvm.org/D118814#3297198>, @JDevlieghere wrote:

> In D118814#3297075 <https://reviews.llvm.org/D118814#3297075>, @jingham wrote:
>
>> In D118814#3296008 <https://reviews.llvm.org/D118814#3296008>, @labath wrote:
>>
>>> This seems fine, though it's not clear to me what is the effect of this patch in terms of functionality. Does the "side-effect" mentioned by Jim still apply here, or is this NFC now? Either is probably fine, but I'd like to understand what is going on. It seems like it should be NFC, but does that mean that the demangling (and the cpu/memory cost) is delayed until the first operation which requests it (such as matching a breakpoint by the full demangled name) ?
>>
>> I haven't gone back to read our lookups in detail, but I certainly hope that the first time we see a breakpoint on a symbol name we don't recognize, we wouldn't go demangling every symbol name in the system.  We really try to keep mistypings from cascading into "unpack the entire world" events.
>
> Yes, this does break the ability to set breakpoints on full demangled names. Based on the code and the comments, it really looks like it was always the intention to avoid demangling the whole name, but then (accidentally?) made it work by storing it in the ConstString. The continue on line 333 is what prevents us from indexing the full name.

That's what I was missing. Thanks.

================
Comment at: lldb/test/API/macosx/dyld-trie-symbols/TestDyldTrieSymbols.py:41
         # make sure we can look up the mangled name, demangled base name,
         # demangled name with argument.
         unstripped_Z3pat_symbols = unstripped_target.FindSymbols("_Z3pati")
----------------
I guess this is no longer true

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118814/new/

https://reviews.llvm.org/D118814