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

[David Blaikie via cfe-commits]

On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
reviews at reviews.llvm.org> wrote:

> 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.
>

I'm actually going back and forth on this ^. It seems to me, regardless of
mangled names, etc, it'd be good if LLVM used the same name for a type in
DWARF across different translation units. And, to a large extent, we do
(the case of typedefs in template parameters doesn't seem to present a
problem for the current implementation - the underlying type is used),
enums being one place where we don't - and we don't actually make it that
much closer to the source/based on what the user wrote.

Even if the user had: "enum X { Y = 0, Z = 0; } ... template<enum X> struct
foo; ... foo<Z>" LLVM still describes that type as "foo<X::Y>". Also if you
have "enum X: int; ... foo<(X)0>" you get "foo<0>" whereas in another
translation unit with a definition of X you'd get "foo<X::Y>".

So for consistency there, I kind of think maybe a change like this isn't
bad.

But of course the specific way a template name is written may easily still
vary between compilers, so relying on it being exactly the same might not
be a great idea anyway...


> 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?).


I think they would have a choice, actually - let's walk through it...

It sounds like you're thinking of two other possibilities:

1) "I suppose, we cannot extend RTTI with the debug type name (is it
correct?)" - yeah, that's probably correct, extending the RTTI format
probably isn't desirable and we'd still need a singular/canonical DWARF
name which we don't seem to have (& the RTTI might go in another object
file that may not have debug info, or debug info generated by a different
compiler with a different type printing format, etc... )

2) Extending DWARF to include the mangled name
Sort of possible, DW_AT_linkage_name on a DW_AT_class could be used for
this just fine - no DWARF extension required.

But an alternative would be to have debuggers use a more semantically aware
matching here. The debugger does have enough information in the DWARF to
semantically match "foo<(X)0>" with "foo<X::Y>". enum X is in the DWARF,
and the enumerator Y is present with its value 0.

Another case of Clang's DWARF type printing differing from a common
demangling, is an unsigned parameter. template<unsigned> foo; foo<0> -
common demangling for this is "foo<0u>" but Clang will happily render the
type as "foo<0>" - this one seems less easy to justify changing than the
enum case (the enum case, given the declared-but-not-defined enum example,
seems more compelling to try to have clang give a consistent name to the
type (which, while not complete (differing compilers could still use
different printings), seems somewhat desirable)) because it's at least
self-consistent.

Again, in this case, a debugger could handle this.

All that said, GDB is the elephant in the room and I imagine might have no
interest in adopting a more complex name lookup/comparison strategy & we
might just have to bow to their demangling printing and naming scheme...
but might be worth asking GDB folks first? Not sure.


> 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?
>
>
> https://reviews.llvm.org/D39622
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171214/a3dac4f2/attachment.html>