dblaikie added a comment. In D76801#1996376 <https://reviews.llvm.org/D76801#1996376>, @labath wrote:
> In D76801#1995058 <https://reviews.llvm.org/D76801#1995058>, @dblaikie wrote: > > > > It becomes a gdb-index problem because with an index the debugger will do > > > a (hashed?) string lookup and expect the string to be there. If the > > > strings differ, the lookup won't find anything. In the no-index scenario, > > > the debugger has to trawl the debug info itself, and so it has some > > > opportunities to do fuzzy matching. > > > > That surprises me a bit - given that one of the things debuggers provide is > > autocomplete (I'm unlikely to write out a type name exactly as the debug > > info contains it - if two compilers can't agree, it's much less likely that > > all users will agree with any compiler rendering), which I'd have thought > > would be facilitated by the index too - in which case lookup via exact > > match wouldn't be viable, you'd still want a way to list anything with a > > matching substring (or at least prefix), etc. Which could help facilitate > > lookup fuzzy matching like in this sort of case. > > > That is kind of true, and I don't really have a definitive reply to that. I > suppose there is a difference between the lookups done for type completion > and those done e.g. in expression evaluation. The latter are probably more > frequent and are assumed to be correct. Maybe they shouldn't be, but in that > cases, then there would probably be no use for the hash tables in indexes (I > am not very familiar with the gdb index, but I know it has hash tables > similar to debug_names/apple_names). I don't know what gdb does for tab > completion, but it probably bypasses the hash table (though the index could > still be useful even then as it has a concise list of all strings in the > debug info), or it gets the list of strings-to-complete from a completely > different source (demangled function names?). > > Tab completion is always a bit dodgy. E.g., in your example `ptype tmpl<TAB>` > completes to `ptype tmpl<tmpl<int>>`, but then running that produces an > error: `No symbol "tmpl" in current context.` > > In lldb, tab completion in expressions works by hooking into the regular > clang tab-completion machinery used by editors. The up- and down-side of > that is that it uses the same code path used for actual expression evaluation > -- i.e. all the types will be looked up the same (exact) way. > > Speaking of templates and indexes, the thing we would really like in lldb > would be to have just the bare names of templated class in the indexes -- > that way we could reliably look up all instantiations of a template and do > the filtering ourselves. However, this runs afoul of the dwarf specification, > which says that the index names should match the DW_AT_names of relevant DIEs > (and these contain the template arguments for other reasons...). This means > that currently we have outstanding issues when looking up templated types, > but we haven't really figured out what to do about that... Yeah, points all taken - as for this actual issue... I'm kind of inclined to say "hey, our template names already diverge somewhat - and this divergence is in the realm of acceptable by gdb (without an index) so... *thumbs up*/let's stick with it" & as I think you mentioned earlier, this is more a problem for the index support, than for the debug info producer. I don't think it's a reasonable goal that Clang & GCC produce /exactly/ the same names for templates like this... I mean, we /could/ try, but I don't think it's worthwhile (especially given that gdb's got support intended to do fuzzy matching/allow some divergence) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76801/new/ https://reviews.llvm.org/D76801 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
