[PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

Anton via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Dec 14 02:21:04 PST 2017

xgsa added a comment.

In https://reviews.llvm.org/D39622#954585, @probinson wrote:

> Philosophically, mangled names and DWARF information serve different purposes, and I don't think you will find one true solution where both of them can yield the same name that everyone will be happy with.  Mangled names exist to provide unique and reproducible identifiers for the "same" entity across compilation units.  They are carefully specified (for example) to allow a linker to associate a reference in one object file to a definition in a different object file, and be guaranteed that the association is correct.  A demangled name is a necessarily context-free translation of the mangled name into something that has a closer relationship to how a human would think of or write the name of the thing, but isn't necessarily the only way to write the name of the thing.
> DWARF names are (deliberately not carefully specified) strings that ought to bear some relationship to how source code would name the thing, but you probably don't want to attach semantic significance to those names.  This is rather emphatically true for names containing template parameters.  Typedefs (and their recent offspring, 'using' aliases) are your sworn enemy here.  Enums, as you have found, are also a problem.
> Basically, the type of an entity does not have a unique name, and trying to coerce different representations of the type into having the same unique name is a losing battle.

Thank you for clarification, Paul! Nevertheless, I suppose, showing actual type of a dynamic variable is very important for the projects, where RTTI is used. Moreover, it works properly in gcc+gdb pair, so I am extremely interested in fixing it in clang+lldb.

I understand that the suggested solution possibly does not cover all the cases, but it improves the situation and actually covers all the cases found by me (I have just rechecked -- typedefs/usings seems to work fine when displaying the real type of variable). If more cases are found in future, they could be fixed similarly too. Moreover, the debuggers already rely on the fact that the type name looks the same in RTTI and DWARF, and I suppose they have no choice, because there is no other source of information for them (or am I missing something?). Another advantage of this solution is that it doesn't require any format extension and will probably work out of the box in gdb and other debuggers. Moreover, I have just rechecked, gcc generates exactly the same type names in DWARF for examples in the description.

On the other hand, I understand the idea you have described, but I am not sure how to implement this lookup in another way. I suppose, we cannot extend RTTI with the debug type name (is it correct?). Thus, the only way I see is to add additional information about the mangled type name into DWARF. It could be either a separate section (like apple_types) or a special node for TAG_structure_type/TAG_class_type, which should be indexed into map for fast lookup. Anyway, this will be an extension to DWARF and will require special support in a debugger. Furthermore, such solution will be much complicated (still I don't mind working on it).

So what do you think? Is the suggested solution not full or not acceptable? Do you have other ideas how this feature should be implemented?

P.S. Should this question be raised in mailing list? And if yes, actually, in which ones (clang or lldb?), because it seems related to both clang and lldb?


More information about the cfe-commits mailing list