<p dir="ltr"><br>
On Sep 9, 2014 6:18 AM, "Frédéric Riss" <<a href="mailto:friss@apple.com">friss@apple.com</a>> wrote:<br>
><br>
><br>
> > On 09 Sep 2014, at 00:01, <a href="mailto:jingham@apple.com">jingham@apple.com</a> wrote:<br>
> ><br>
> > From the debugger's standpoint, the functional concern is that if you do something more real, like:<br>
> ><br>
> > typedef int A;<br>
> > template <typename T><br>
> > struct S<br>
> > {<br>
> > T my_t;<br>
> > };<br>
> ><br>
> > I want to make sure that the type of my_t is given as "A" not as "int". The reason for that is that it is not uncommon to have data formatters that trigger off the typedef name. This happens when you use some common underlying type like "int" but the value has some special meaning when it is formally an "A", and you want to use the data formatters to give it an appropriate presentation. Since the data formatters work by matching type name, starting from the most specific on down, it is important that the typedef name be preserved.<br>
> ><br>
> > However, it would be really odd to see:<br>
> ><br>
> > (lldb) expr -T -- my_s<br>
> > (S<int>) $1 = {<br>
> > (A) my_t = 5<br>
> > }<br>
> ><br>
> > instead of:<br>
> ><br>
> > (lldb) expr -T -- my_s<br>
> > (S<A>) $1 = {<br>
> > (A) my_t = 5<br>
> > }<br>
> ><br>
> > so I am in favor of presenting the template parameter type with the most specific name it was given in the overall template type name.<br>
><br>
> OK, we get this wrong today. I’ll try to look into it.<br>
><br>
> What’s your take on the debug info representation for the templated class type? The tentative patch introduces a typedef that declares S<A> as a typedef for S<int>. The typedef doesn’t exist in the code, thus I find it a bit of a lie to the debugger. I was more in favour of something like :<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>
> This way the canonical type is kept in the debug information, and the declaration type is a real class type aliasing the canonical type. But I’m not sure debuggers can digest this kind of aliasing.</p>
<p dir="ltr">I assume this is more a discussion to have with the dwarf committee to get a sense of what consumers want, etc.</p>
<p dir="ltr">If not for that, I would assume using a typedef (you could add DW_tag_artificial in either of your proposals to make it sort of clear) would work for free on any debugger today, whereas the structure_type might cause some confusion/problems. (Testing on a few current consumers would be helpful)</p>
<p dir="ltr">- Davod</p>
<p dir="ltr">><br>
> Fred<br>
><br>
><br>
> > Jim<br>
> ><br>
> >> On Sep 8, 2014, at 12:38 PM, Frédéric Riss <<a href="mailto:friss@apple.com">friss@apple.com</a>> wrote:<br>
> >><br>
> >><br>
> >>> On 08 Sep 2014, at 19:31, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> >>><br>
> >>> This means you will see "S<A>" as the type for your variables in the debugger when you view variables or children of structs/unions/classes. I think this is not what the user would want to see. I would rather see "S<int>" as the type for my variable than see "S<A>”.<br>
> >><br>
> >> I find it more accurate for the debugger to report what has actually been put in the code. Moreover when a typedef is used, it’s usually to make things more readable not to hide information, thus I guess it would usually be as informative while being more compact. The debugger needs to have a way to describe the real type behind the abbreviated name though, we must not have less information compared to what we have today.<br>
> >><br>
> >> Another point: this allows the debugger to know what S<A> actually is. Without it, the debugger only knows the canonical type. This means that currently you can’t copy/paste a piece of code that references that kind of template names and have it parse correctly. I /think/ that having this information in the debug info will allow more of this to work.<br>
> >><br>
> >> But we can agree to disagree :-) It would be great to have more people chime and give their opinion.<br>
> >><br>
> >> Fred<br>
> >><br>
> >>>> On Sep 5, 2014, at 4:00 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
> >>>><br>
> >>>><br>
> >>>>> On Sep 5, 2014, at 3:49 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> On Fri, Sep 5, 2014 at 3:43 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> >>>>><br>
> >>>>>> On 2014 Sep 5, at 16:01, Frédéric Riss <<a href="mailto:friss@apple.com">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>
> >>>>> If you specify `vector<int>` in C++ do you get that instead of<br>
> >>>>> `vector<int, std::__1::allocator<int>>`?<br>
> >>>>><br>
> >>>>> Yeah, I mentioned this as possibly causing problems with debuggers or other consumers, but I don't have any proof past "ooooo scary!”.<br>
> >>>><br>
> >>>> Well, [+lldb-dev], could this confuse debuggers? :-)<br>
> >>>><br>
> >>>> -- adrian<br>
> >>>>><br>
> >>>>> That said, I like the idea personally :)<br>
> >>>>><br>
> >>>>> -eric<br>
> >>>>><br>
> >>>>><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>
> >>>>> 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">llvm-commits@cs.uiuc.edu</a><br>
> >>>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> >>>>><br>
> >>>>><br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> lldb-dev mailing list<br>
> >>>> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> >>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
> >>><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> lldb-dev mailing list<br>
> >> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
> ><br>
><br>
</p>