<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 4:00 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Sep 5, 2014, at 3:49 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 3:43 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
> On 2014 Sep 5, at 16:01, Frédéric Riss <<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>> wrote:<br>
><br>
> I couldn’t even find a subject expressing exactly what this patch is about… First of all, it’s meant to start a discussion, and I’m not proposing it for inclusion right now.<br>
><br>
> The issue I’m trying to address is that template types are always canonicalized when emitted in the debug information (this is the desugar() call in UnwrapTypeForDebugInformation).<br>
><br>
> This means that if the developer writes:<br>
><br>
> typedef int A;<br>
> template <typename T><br>
> struct S {};<br>
><br>
> S<A> var;<br>
><br>
> The variable var will have type S<int> and not S<A>. In this simple example, it’s not that much of an issue, but for heavily templated code, the full expansion might be really different from the original declaration.<br>
><br>
> The attached patch makes us emit an intermediate typedef for the variable’s type:<br>
><br>
> 0x0000002a:   DW_TAG_variable [2]<br>
>                DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000032] = “var")<br>
>                DW_AT_type [DW_FORM_ref4]       (cu + 0x0040 => {0x00000040})<br>
>                DW_AT_external [DW_FORM_flag]   (0x01)<br>
>                DW_AT_decl_file [DW_FORM_data1] (0x01)<br>
>                DW_AT_decl_line [DW_FORM_data1] (8)<br>
>                DW_AT_location [DW_FORM_block1] (<0x09> 03 70 6c 00 00 00 00 00 00 )<br>
><br>
> 0x00000040:   DW_TAG_typedef [3]<br>
>                DW_AT_type [DW_FORM_ref4]       (cu + 0x004b => {0x0000004b})<br>
>                DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000035] = “S<A>")<br>
>                DW_AT_decl_file [DW_FORM_data1] (0x01)<br>
>                DW_AT_decl_line [DW_FORM_data1] (6)<br>
><br>
> 0x0000004b:   DW_TAG_structure_type [4] *<br>
>                DW_AT_name [DW_FORM_strp]       ( .debug_str[0x0000003e] = “S<int>")<br>
>                DW_AT_byte_size [DW_FORM_data1] (0x01)<br>
>                DW_AT_decl_file [DW_FORM_data1] (0x01)<br>
>                DW_AT_decl_line [DW_FORM_data1] (6)<br>
><br>
><br>
> Which basically is what I want, although I don’t like that it introduces a typedef where there is none in the code. I’d prefer that to be:<br>
><br>
> DW_TAG_variable<br>
>  DW_AT_type: -> DW_TAG_structure_type<br>
>                   DW_AT_name: S<A><br>
>                   DW_AT_specification: -> DW_TAG_structure_type<br>
>                                             DW_AT_name: S<int><br>
>                                             …<br>
><br>
> The patch also has the nice property of omitting the defaulted template arguments in the first level typedef. For example you get vector<A> instead of vector<int, std::__1::allocator<int> >.<br>
<br>
</div></div>If you specify `vector<int>` in C++ do you get that instead of<br>
`vector<int, std::__1::allocator<int>>`?<br></blockquote><div><br></div><div>Yeah, I mentioned this as possibly causing problems with debuggers or other consumers, but I don't have any proof past "ooooo scary!”.</div></div></div></div></div></blockquote><div><br></div></div></div>Well, [+lldb-dev], could this confuse debuggers? :-)</div></div></blockquote><div><br></div><div>*bugs random gdb developer as well*</div><div><br></div><div>-eric </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">-- adrian</font></span><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>That said, I like the idea personally :)</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Now there is one thing I really don’t like about the patch. In order not to emit typedefs for types that don’t need it, I use string comparison between the desugared and the original type. I haven’t quantified anything, but doing the construction of the type name for every template type and then comparing it to decide to use it or not seems like a big waste.<br>
<br>
</span>Maybe someone on cfe-dev knows a better way.<br>
<br>
><br>
> Thoughts?<br>
><br>
> <template-arg-typedefs.diff><br>
><br>
> Fred<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote></div><br></div></div>
</div></blockquote></span></div><br></div></blockquote></div><br></div></div>