[RFC] Improve Dwarf 5 .debug_names Type Lookup/Parsing Speed

[dblaikie]

@clayborg

Yes this does reduce string table sizes when enabled. Simple template names are not great for type manual type lookups by exact name though, not expression parsing here, just a simple type lookup by a user.

Do you have a small/standalone example?

Simple template name accelerator table entries get ignored because they mess things up compared to normal DWARF.

Hmm, that’s not my understanding - again, perhaps a small/concrete example would be helpful to discuss?

(my understanding was we did the work to address -gsimple-template-names usage in lldb: [DWARF] using simplified template names - #13 by dblaikie and ⚙ D134378 [lldb] Support simplified template names )

@dblaikie

Because as it is today, my understanding is that the simplified names are still used for index lookups - but they’re ambiguous. Are you saying they aren’t used and then what? The index is ignored and manual parsing is done again?

No just ignored because they don’t match normal DWARF. The simple template names interfere with expression evaluation as vector would match any vector<T>

Hmm - how does that square with the work done in D134378? Was that work incomplete? I’d like to know more about how to ensure this is working well.

@dblaikie

When you say “standard accelerator table” - what are you comparing/contrasting that to? Do you mean a .debug_names accelerator table, but without simplified names?

yes that is what I mean. These compiler features often get enabled without knowing if they affect debugging and they often do, so we have to learn to work around any
features that might get enabled.

I don’t believe that was the case with -gsimple-template-names - we did make an effort to ensure it works with lldb.

But you mentioned up top you’re concerned about something else/not human spellings and I’m still a bit confused by that - perhaps we can dig into that further.

I am just talking about how types are requested during expression evaluation for clang. First “std”, then “find ‘vector’ inside of ‘std’”, etc.

During type lookups for the expression parser, we often know the decl context that must contain a type like “iterator”, so we know we are looking for std::vector<int>::iterator, but when we do lookups for this type using accelerator tables, we must use the basename iterator and filter out results that don’t match

Once you reach a class type, though, like std::vector<int> would it be feasible to search inside the DWARF description or Clang AST of that type, rather than consulting the context-free index? (I understand this wouldn’t be the right choice for a namespace, like std, but for class members, it’s a bit more bounded - and “members of std::vector<int>” is probably a smaller list than “all entities named iterator”, for instance)