[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:36:03 PST 2017
Not much - I've put them on this part of the thread specifically to raise
attention.
If it doesn't get visibility here, maybe a cfe-dev thread would be good.
On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov <xgsa at yandex.ru> wrote:
> Sorry, I am quite new to the process. It seems, Adrian and Paul are in the
> reviewers/subscribers list to the original review (
> https://reviews.llvm.org/D39622). Should I do something else?
> 19.12.2017 23:06, David Blaikie wrote:
>
> 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/0049634e/attachment-0001.html>
More information about the cfe-commits
mailing list