<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<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; 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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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:dblaikie@gmail.com]
<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; mlekena@skidmore.edu; reviews+D39622+public+b0839896b45cd5f6@reviews.llvm.org; cfe-commits@lists.llvm.org; shenhan@google.com<br>
<b>Subject:</b> Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></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>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov <<a href="mailto:xgsa@yandex.ru">xgsa@yandex.ru</a>> wrote:<o:p></o:p></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?<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">19.12.2017 23:06, David Blaikie wrote:<o:p></o:p></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)<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></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:<o:p></o:p></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><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>