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

[David Blaikie via cfe-commits]

On Tue, Dec 19, 2017 at 1:50 PM Robinson, Paul 
wrote:

> On the lldb-dev thread I thought this was a reasonable idea
> (DW_AT_linkage_name on types) but given the use-case, probably best to
> confine it to classes with vtables?  If there's a broader use-case it
> wasn't clear from the other thread;
>

Yeah, that's the only one I know of from these conversations.


> there it was reported that LLDB really only uses the mangled name for
> tracking down the type description associated with a vtable (which of
> course has a mangled name giving the type).
>

GDB seems to use it for this too - no idea if it has other uses for exact
matching of demangled symbol names with type names in DWARF.


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Tuesday, December 19, 2017 1:36 PM
> *To:* Anton Gorenkov; Robinson, Paul; Adrian Prantl
> *Cc:* xgsa; mlek...@skidmore.edu;
> reviews+d39622+public+b0839896b45cd...@reviews.llvm.org;
> cfe-commits@lists.llvm.org; shen...@google.com
> *Subject:* Re: [PATCH] D39622: Fix type name generation in DWARF for
> template instantiations with enum types and template specializations
>
>
>
> 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  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  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  > > 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"  > >:
> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
> >> 

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

[Robinson, Paul via cfe-commits]

On the lldb-dev thread I thought this was a reasonable idea (DW_AT_linkage_name 
on types) but given the use-case, probably best to confine it to classes with 
vtables?  If there's a broader use-case it wasn't clear from the other thread; 
there it was reported that LLDB really only uses the mangled name for tracking 
down the type description associated with a vtable (which of course has a 
mangled name giving the type).
--paulr

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Tuesday, December 19, 2017 1:36 PM
To: Anton Gorenkov; Robinson, Paul; Adrian Prantl
Cc: xgsa; mlek...@skidmore.edu; 
reviews+d39622+public+b0839896b45cd...@reviews.llvm.org; 
cfe-commits@lists.llvm.org; shen...@google.com
Subject: Re: [PATCH] D39622: Fix type name generation in DWARF for template 
instantiations with enum types and template specializations

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 
> 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 
> 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 
> >> 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" 
> 
> >>:
>> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
>>  
>> >> wrote:
>>
>> xgsa added a comment.
>>
>> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>>
>> > Philosophically, mangled names and DWARF information serve
>> different 

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

[David Blaikie via cfe-commits]

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  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  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 > > > 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" > > >:
>> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
>> >> >
>> 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 

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

[Anton Gorenkov via cfe-commits]

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 > 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 
> >> 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" 
>     >>:
>>     On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
>>     
>> 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 

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

[David Blaikie via cfe-commits]

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  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  > > 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"  > >:
> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
> >> > 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.
> >>

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

[David Blaikie via cfe-commits]

On Fri, Dec 15, 2017 at 8:09 AM xgsa  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" :
>
>
> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
> revi...@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
> struct foo; ... foo" LLVM still describes that type as "foo". 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".
>
> 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 

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

[xgsa via cfe-commits]

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. 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. Still, should this topic be raised in cde-dev or are all the interested people already here? [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html 14.12.2017, 22:40, "David Blaikie" : On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator  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 struct foo; ... foo" LLVM still describes that type as "foo". 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".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 nameSort of possible, DW_AT_linkage_name on a DW_AT_class could be used for this just fine - no DWARF 

Re: [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 <
revi...@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 struct
foo; ... foo" LLVM still describes that type as "foo". 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".

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

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

[Anton via Phabricator via cfe-commits]

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?


https://reviews.llvm.org/D39622



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

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.


https://reviews.llvm.org/D39622



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Anton via Phabricator via cfe-commits]

xgsa updated this revision to Diff 126826.
xgsa retitled this revision from "Fix type debug information generation for 
enum-based template specialization" to "Fix type name generation in DWARF for 
template instantiations with enum types and template specializations".
xgsa edited the summary of this revision.
xgsa added a comment.
Herald added a subscriber: JDevlieghere.

One more case was handled, review comments were applied, but no tests though, 
because I still not sure if the approach I have chosen is correct.


https://reviews.llvm.org/D39622

Files:
  include/clang/AST/PrettyPrinter.h
  lib/AST/TemplateBase.cpp
  lib/AST/TypePrinter.cpp
  lib/CodeGen/CGDebugInfo.cpp


Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -234,6 +234,7 @@
   if (CGM.getCodeGenOpts().EmitCodeView)
 PP.MSVCFormatting = true;
 
+  PP.ABICompatibleFormatting = true;
   return PP;
 }
 
Index: lib/AST/TypePrinter.cpp
===
--- lib/AST/TypePrinter.cpp
+++ lib/AST/TypePrinter.cpp
@@ -1060,7 +1060,9 @@
   if (ClassTemplateSpecializationDecl *Spec
 = dyn_cast(D)) {
 ArrayRef Args;
-if (TypeSourceInfo *TAW = Spec->getTypeAsWritten()) {
+if (TypeSourceInfo *TAW = !Policy.ABICompatibleFormatting
+  ? Spec->getTypeAsWritten()
+  : nullptr) {
   const TemplateSpecializationType *TST =
 cast(TAW->getType());
   Args = TST->template_arguments();
Index: lib/AST/TemplateBase.cpp
===
--- lib/AST/TemplateBase.cpp
+++ lib/AST/TemplateBase.cpp
@@ -56,14 +56,22 @@
   const llvm::APSInt  = TemplArg.getAsIntegral();
 
   if (const EnumType *ET = T->getAs()) {
-for (const EnumConstantDecl* ECD : ET->getDecl()->enumerators()) {
-  // In Sema::CheckTemplateArugment, enum template arguments value are
-  // extended to the size of the integer underlying the enum type.  This
-  // may create a size difference between the enum value and template
-  // argument value, requiring isSameValue here instead of operator==.
-  if (llvm::APSInt::isSameValue(ECD->getInitVal(), Val)) {
-ECD->printQualifiedName(Out, Policy);
-return;
+if (Policy.ABICompatibleFormatting) {
+  Out << "(";
+  ET->getDecl()->getNameForDiagnostic(Out, Policy, true);
+  Out << ")";
+  Out << Val;
+  return;
+} else {
+  for (const EnumConstantDecl* ECD : ET->getDecl()->enumerators()) {
+// In Sema::CheckTemplateArugment, enum template arguments value are
+// extended to the size of the integer underlying the enum type.  This
+// may create a size difference between the enum value and template
+// argument value, requiring isSameValue here instead of operator==.
+if (llvm::APSInt::isSameValue(ECD->getInitVal(), Val)) {
+  ECD->printQualifiedName(Out, Policy);
+  return;
+}
   }
 }
   }
Index: include/clang/AST/PrettyPrinter.h
===
--- include/clang/AST/PrettyPrinter.h
+++ include/clang/AST/PrettyPrinter.h
@@ -52,7 +52,7 @@
   Half(LO.Half), MSWChar(LO.MicrosoftExt && !LO.WChar),
   IncludeNewlines(true), MSVCFormatting(false),
   ConstantsAsWritten(false), SuppressImplicitBase(false),
-  FullyQualifiedName(false) { }
+  FullyQualifiedName(false), ABICompatibleFormatting(false) { }
 
   /// Adjust this printing policy for cases where it's known that we're
   /// printing C++ code (for instance, if AST dumping reaches a C++-only
@@ -225,6 +225,13 @@
   /// When true, print the fully qualified name of function declarations.
   /// This is the opposite of SuppressScope and thus overrules it.
   bool FullyQualifiedName : 1;
+
+  /// Use formatting compatible with ABI specification. It is necessary for
+  /// saving entities into debug tables which have to be compatible with
+  /// the representation, described in ABI specification. In particular, this 
forces
+  /// templates parametrized with enums to be represented as "T<(Enum)0>" 
instead of
+  /// "T" and template specializations to be written in canonical 
form.
+  bool ABICompatibleFormatting : 1;
 };
 
 } // end namespace clang


Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -234,6 +234,7 @@
   if (CGM.getCodeGenOpts().EmitCodeView)
 PP.MSVCFormatting = true;
 
+  PP.ABICompatibleFormatting = true;
   return PP;
 }
 
Index: lib/AST/TypePrinter.cpp
===
--- lib/AST/TypePrinter.cpp
+++ lib/AST/TypePrinter.cpp
@@ -1060,7 +1060,9 @@
   if (ClassTemplateSpecializationDecl *Spec