<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 19, 2017 at 1:50 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-1298481390390819813WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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; </span></p></div></div></blockquote><div><br>Yeah, that's the only one I know of from these conversations.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-1298481390390819813WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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).</span></p></div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-1298481390390819813WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-1298481390390819813__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, December 19, 2017 1:36 PM<br>
<b>To:</b> Anton Gorenkov; Robinson, Paul; Adrian Prantl<br>
<b>Cc:</b> xgsa; <a href="mailto:mlekena@skidmore.edu" target="_blank">mlekena@skidmore.edu</a>; <a href="mailto:reviews%2BD39622%2Bpublic%2Bb0839896b45cd5f6@reviews.llvm.org" target="_blank">reviews+D39622+public+b0839896b45cd5f6@reviews.llvm.org</a>; <a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>; <a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a><br>
<b>Subject:</b> Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations<u></u><u></u></span></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-1298481390390819813WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Not much - I've put them on this part of the thread specifically to raise attention.<br>
<br>
If it doesn't get visibility here, maybe a cfe-dev thread would be good.<br>
<br>
<br>
<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov <<a href="mailto:xgsa@yandex.ru" target="_blank">xgsa@yandex.ru</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p>Sorry, I am quite new to the process. It seems, Adrian and Paul are in the reviewers/subscribers list to the original review (<a href="https://reviews.llvm.org/D39622" target="_blank">https://reviews.llvm.org/D39622</a>). Should I do something else?<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">19.12.2017 23:06, David Blaikie wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">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)<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov <<a href="mailto:xgsa@yandex.ru" target="_blank">xgsa@yandex.ru</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">There was a discussion in lldb-dev mailing list on this topic and I<br>
suppose a reliable solution was suggested [1]. It is to generate<br>
DW_AT_linkage_name for vtable DIE of a class and provide an additional<br>
accelerator table. I am going to try to implement this approach (it will<br>
require some work on both clang and lldb sides), but I'd like also to<br>
understand if I should discard or complete the current patch. Certainly,<br>
I'd prefer to complete it if it could be applied (I suppose, at least<br>
tests should be added), because even with long term solution implemented<br>
in clang/lldb, gdb still won't resolve dynamic types properly for the<br>
described cases.<br>
<br>
[1] - <a href="http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html" target="_blank">
http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html</a><br>
<br>
15.12.2017 21:25, David Blaikie via cfe-commits wrote:<br>
><br>
><br>
> On Fri, Dec 15, 2017 at 8:09 AM xgsa <<a href="mailto:xgsa@yandex.ua" target="_blank">xgsa@yandex.ua</a><br>
> <mailto:<a href="mailto:xgsa@yandex.ua" target="_blank">xgsa@yandex.ua</a>>> wrote:<br>
><br>
>     David, thank you for the detailed answer and corner cases.<br>
>     Just to clarify: everywhere in my mail where I mentioned<br>
>     "debugger", I meant LLDB, but not GDB (except, where I mentioned<br>
>     GDB explicitly). Currently, I have no plans to work on GDB,<br>
>     however I would like to make the clang+LLDB pair working in such<br>
>     cases.<br>
><br>
><br>
> *nod* My concern is making sure, if possible, we figure out a design<br>
> that seems viable long-term/in general. (& if we figure out what that<br>
> design is, but decide it's not achievable immediately, we can make<br>
> deliberate tradeoffs, document the long term goal & what the short<br>
> term solutions cost relative to that goal, etc)<br>
><br>
>     Thus, I have described your idea in the lldb-dev mailing list [1].<br>
>     Still, I have some concerns about the performance of such<br>
>     semantically aware matching. Currently, with acceleration tables<br>
>     (e.g. apple_types etc) the matching is as fast as lookup in hash<br>
>     map and hash map is loade almost without postprocessing.<br>
>     Semantically aware matching will require either processing during<br>
>     statup or almost linear lookup.<br>
><br>
><br>
> Yep, I agree - that seems like a reasonable concern. I wonder whether<br>
> it'd be reasonable to put accelerator table entries containing the<br>
> base name of the template to ease such lookup?<br>
><br>
>      Still, should this topic be raised in cde-dev or are all the<br>
>     interested people already here?<br>
><br>
><br>
> Yeah, might be worth moving this to a thread there. Though we probably<br>
> have all the right people here, it's a better spot for the<br>
> conversation even for spectators, history (finding this later when we<br>
> have similar questions, etc), etc.<br>
><br>
>     [1] -<br>
>     <a href="http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html" target="_blank">http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html</a><br>
>     14.12.2017, 22:40, "David Blaikie" <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a><br>
>     <mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>>:<br>
>>     On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator<br>
>>     <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a> <mailto:<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>>> wrote:<br>
>><br>
>>         xgsa added a comment.<br>
>><br>
>>         In <a href="https://reviews.llvm.org/D39622#954585" target="_blank">https://reviews.llvm.org/D39622#954585</a>, @probinson wrote:<br>
>><br>
>>         > Philosophically, mangled names and DWARF information serve<br>
>>         different purposes, and I don't think you will find one true<br>
>>         solution where both of them can yield the same name that<br>
>>         everyone will be happy with.  Mangled names exist to provide<br>
>>         unique and reproducible identifiers for the "same" entity<br>
>>         across compilation units.  They are carefully specified (for<br>
>>         example) to allow a linker to associate a reference in one<br>
>>         object file to a definition in a different object file, and<br>
>>         be guaranteed that the association is correct.  A demangled<br>
>>         name is a necessarily context-free translation of the mangled<br>
>>         name into something that has a closer relationship to how a<br>
>>         human would think of or write the name of the thing, but<br>
>>         isn't necessarily the only way to write the name of the thing.<br>
>>         ><br>
>>         > DWARF names are (deliberately not carefully specified)<br>
>>         strings that ought to bear some relationship to how source<br>
>>         code would name the thing, but you probably don't want to<br>
>>         attach semantic significance to those names.  This is rather<br>
>>         emphatically true for names containing template parameters. <br>
>>         Typedefs (and their recent offspring, 'using' aliases) are<br>
>>         your sworn enemy here.  Enums, as you have found, are also a<br>
>>         problem.<br>
>>         ><br>
>>         > Basically, the type of an entity does not have a unique<br>
>>         name, and trying to coerce different representations of the<br>
>>         type into having the same unique name is a losing battle.<br>
>><br>
>><br>
>>     I'm actually going back and forth on this ^. It seems to me,<br>
>>     regardless of mangled names, etc, it'd be good if LLVM used the<br>
>>     same name for a type in DWARF across different translation units.<br>
>>     And, to a large extent, we do (the case of typedefs in template<br>
>>     parameters doesn't seem to present a problem for the current<br>
>>     implementation - the underlying type is used), enums being one<br>
>>     place where we don't - and we don't actually make it that much<br>
>>     closer to the source/based on what the user wrote.<br>
>><br>
>>     Even if the user had: "enum X { Y = 0, Z = 0; } ... template<enum<br>
>>     X> struct foo; ... foo<Z>" LLVM still describes that type as<br>
>>     "foo<X::Y>". Also if you have "enum X: int; ... foo<(X)0>" you<br>
>>     get "foo<0>" whereas in another translation unit with a<br>
>>     definition of X you'd get "foo<X::Y>".<br>
>><br>
>>     So for consistency there, I kind of think maybe a change like<br>
>>     this isn't bad.<br>
>><br>
>>     But of course the specific way a template name is written may<br>
>>     easily still vary between compilers, so relying on it being<br>
>>     exactly the same might not be a great idea anyway...<br>
>><br>
>>         Thank you for clarification, Paul! Nevertheless, I suppose,<br>
>>         showing actual type of a dynamic variable is very important<br>
>>         for the projects, where RTTI is used. Moreover, it works<br>
>>         properly in gcc+gdb pair, so I am extremely interested in<br>
>>         fixing it in clang+lldb.<br>
>><br>
>>         I understand that the suggested solution possibly does not<br>
>>         cover all the cases, but it improves the situation and<br>
>>         actually covers all the cases found by me (I have just<br>
>>         rechecked -- typedefs/usings seems to work fine when<br>
>>         displaying the real type of variable). If more cases are<br>
>>         found in future, they could be fixed similarly too. Moreover,<br>
>>         the debuggers already rely on the fact that the type name<br>
>>         looks the same in RTTI and DWARF, and I suppose they have no<br>
>>         choice, because there is no other source of information for<br>
>>         them (or am I missing something?).<br>
>><br>
>><br>
>>     I think they would have a choice, actually - let's walk through<br>
>>     it...<br>
>><br>
>>     It sounds like you're thinking of two other possibilities:<br>
>><br>
>>     1) "I suppose, we cannot extend RTTI with the debug type name (is<br>
>>     it correct?)" - yeah, that's probably correct, extending the RTTI<br>
>>     format probably isn't desirable and we'd still need a<br>
>>     singular/canonical DWARF name which we don't seem to have (& the<br>
>>     RTTI might go in another object file that may not have debug<br>
>>     info, or debug info generated by a different compiler with a<br>
>>     different type printing format, etc... )<br>
>><br>
>>     2) Extending DWARF to include the mangled name<br>
>>     Sort of possible, DW_AT_linkage_name on a DW_AT_class could be<br>
>>     used for this just fine - no DWARF extension required.<br>
>><br>
>>     But an alternative would be to have debuggers use a more<br>
>>     semantically aware matching here. The debugger does have enough<br>
>>     information in the DWARF to semantically match "foo<(X)0>" with<br>
>>     "foo<X::Y>". enum X is in the DWARF, and the enumerator Y is<br>
>>     present with its value 0.<br>
>><br>
>>     Another case of Clang's DWARF type printing differing from a<br>
>>     common demangling, is an unsigned parameter. template<unsigned><br>
>>     foo; foo<0> - common demangling for this is "foo<0u>" but Clang<br>
>>     will happily render the type as "foo<0>" - this one seems less<br>
>>     easy to justify changing than the enum case (the enum case, given<br>
>>     the declared-but-not-defined enum example, seems more compelling<br>
>>     to try to have clang give a consistent name to the type (which,<br>
>>     while not complete (differing compilers could still use different<br>
>>     printings), seems somewhat desirable)) because it's at least<br>
>>     self-consistent.<br>
>><br>
>>     Again, in this case, a debugger could handle this.<br>
>><br>
>>     All that said, GDB is the elephant in the room and I imagine<br>
>>     might have no interest in adopting a more complex name<br>
>>     lookup/comparison strategy & we might just have to bow to their<br>
>>     demangling printing and naming scheme... but might be worth<br>
>>     asking GDB folks first? Not sure.<br>
>><br>
>>         Another advantage of this solution is that it doesn't require<br>
>>         any format extension and will probably work out of the box in<br>
>>         gdb and other debuggers. Moreover, I have just rechecked, gcc<br>
>>         generates exactly the same type names in DWARF for examples<br>
>>         in the description.<br>
>><br>
>>         On the other hand, I understand the idea you have described,<br>
>>         but I am not sure how to implement this lookup in another<br>
>>         way. I suppose, we cannot extend RTTI with the debug type<br>
>>         name (is it correct?). Thus, the only way I see is to add<br>
>>         additional information about the mangled type name into<br>
>>         DWARF. It could be either a separate section (like<br>
>>         apple_types) or a special node for<br>
>>         TAG_structure_type/TAG_class_type, which should be indexed<br>
>>         into map for fast lookup. Anyway, this will be an extension<br>
>>         to DWARF and will require special support in a debugger.<br>
>>         Furthermore, such solution will be much complicated (still I<br>
>>         don't mind working on it).<br>
>><br>
>>         So what do you think? Is the suggested solution not full or<br>
>>         not acceptable? Do you have other ideas how this feature<br>
>>         should be implemented?<br>
>><br>
>>         P.S. Should this question be raised in mailing list? And if<br>
>>         yes, actually, in which ones (clang or lldb?), because it<br>
>>         seems related to both clang and lldb?<br>
>><br>
>><br>
>>         <a href="https://reviews.llvm.org/D39622" target="_blank">https://reviews.llvm.org/D39622</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank">
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><u></u><u></u></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
</div>
</div>
</div></div></div></blockquote></div></div>