dblaikie added a comment. In D76801#1994003 <https://reviews.llvm.org/D76801#1994003>, @labath wrote:
> In D76801#1993337 <https://reviews.llvm.org/D76801#1993337>, @dblaikie wrote: > > > In D76801#1991904 <https://reviews.llvm.org/D76801#1991904>, @labath wrote: > > > > > David's example does work with gdb without -Wl,--gdb-index (the member > > > variable is shown), presumably due to the aforementioned fuzzy matching. > > > However, it does not work if gdb-index is enabled, nor with lldb (as > > > lldb is always very index-oriented and assumes equality everywhere). That > > > is definitely not ideal, though I'm not sure that means about this patch. > > > This is definitely not the only difference in the formatting of > > > DW_AT_names of templates. For example, `template<typename T> > > > operator<<(T, T)` will come out as `operator<< <A>` with gcc, but as > > > `operator<<<A>` with clang (with or without this patch). > > > OTOH, differences in type names are more likely to cause problems than > > > is the case for functions/operators. > > > > > > That is concerning. Any idea if that's only with lld's gdb-indexx > > implementation, or also gold's? > > > I was using gold for my initial test. However, the same thing happens with > lld too... Good to know! Thanks for checking! >> This isn't the only naming divergence between GCC and Clang, though, so if >> gdb-index doesn't support any divergence, that's a problem... > > 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. 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
