[PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations
David Blaikie via cfe-commits
cfe-commits at lists.llvm.org
Tue Dec 19 13:06:28 PST 2017
Yep, could be worth having a conversation with the GDB folks and/or at
least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
interesting since he works with/on another (not LLDB nor GDB) debugger
which would have to think about this
functionality/feature/issue/data/limitation)
On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov <xgsa at yandex.ru> wrote:
> There was a discussion in lldb-dev mailing list on this topic and I
> suppose a reliable solution was suggested [1]. It is to generate
> DW_AT_linkage_name for vtable DIE of a class and provide an additional
> accelerator table. I am going to try to implement this approach (it will
> require some work on both clang and lldb sides), but I'd like also to
> understand if I should discard or complete the current patch. Certainly,
> I'd prefer to complete it if it could be applied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
> >
> >
> > On Fri, Dec 15, 2017 at 8:09 AM xgsa <xgsa at yandex.ua
> > <mailto:xgsa at yandex.ua>> wrote:
> >
> > David, thank you for the detailed answer and corner cases.
> > Just to clarify: everywhere in my mail where I mentioned
> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
> > GDB explicitly). Currently, I have no plans to work on GDB,
> > however I would like to make the clang+LLDB pair working in such
> > cases.
> >
> >
> > *nod* My concern is making sure, if possible, we figure out a design
> > that seems viable long-term/in general. (& if we figure out what that
> > design is, but decide it's not achievable immediately, we can make
> > deliberate tradeoffs, document the long term goal & what the short
> > term solutions cost relative to that goal, etc)
> >
> > Thus, I have described your idea in the lldb-dev mailing list [1].
> > Still, I have some concerns about the performance of such
> > semantically aware matching. Currently, with acceleration tables
> > (e.g. apple_types etc) the matching is as fast as lookup in hash
> > map and hash map is loade almost without postprocessing.
> > Semantically aware matching will require either processing during
> > statup or almost linear lookup.
> >
> >
> > Yep, I agree - that seems like a reasonable concern. I wonder whether
> > it'd be reasonable to put accelerator table entries containing the
> > base name of the template to ease such lookup?
> >
> > Still, should this topic be raised in cde-dev or are all the
> > interested people already here?
> >
> >
> > Yeah, might be worth moving this to a thread there. Though we probably
> > have all the right people here, it's a better spot for the
> > conversation even for spectators, history (finding this later when we
> > have similar questions, etc), etc.
> >
> > [1] -
> > http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
> > 14.12.2017, 22:40, "David Blaikie" <dblaikie at gmail.com
> > <mailto:dblaikie at gmail.com>>:
> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
> >> <reviews at reviews.llvm.org <mailto: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
> >>
> >>
> >
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171219/8d0c859b/attachment-0001.html>
More information about the cfe-commits
mailing list