> On 08 Sep 2014, at 19:31, Greg Clayton <gclay...@apple.com> wrote:
>
> 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>”.
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.
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.
But we can agree to disagree :-) It would be great to have more people chime
and give their opinion.
Fred
>> On Sep 5, 2014, at 4:00 PM, Adrian Prantl <apra...@apple.com> wrote:
>>
>>
>>> On Sep 5, 2014, at 3:49 PM, Eric Christopher <echri...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Sep 5, 2014 at 3:43 PM, Duncan P. N. Exon Smith
>>> <dexonsm...@apple.com> wrote:
>>>
>>>> On 2014 Sep 5, at 16:01, Frédéric Riss <fr...@apple.com> wrote:
>>>>
>>>> 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.
>>>>
>>>> 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).
>>>>
>>>> This means that if the developer writes:
>>>>
>>>> typedef int A;
>>>> template <typename T>
>>>> struct S {};
>>>>
>>>> S<A> var;
>>>>
>>>> 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.
>>>>
>>>> The attached patch makes us emit an intermediate typedef for the
>>>> variable’s type:
>>>>
>>>> 0x0000002a: DW_TAG_variable [2]
>>>> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000032] =
>>>> “var")
>>>> DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040})
>>>> DW_AT_external [DW_FORM_flag] (0x01)
>>>> DW_AT_decl_file [DW_FORM_data1] (0x01)
>>>> DW_AT_decl_line [DW_FORM_data1] (8)
>>>> DW_AT_location [DW_FORM_block1] (<0x09> 03 70 6c 00 00 00 00
>>>> 00 00 )
>>>>
>>>> 0x00000040: DW_TAG_typedef [3]
>>>> DW_AT_type [DW_FORM_ref4] (cu + 0x004b => {0x0000004b})
>>>> DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000035] =
>>>> “S<A>")
>>>> DW_AT_decl_file [DW_FORM_data1] (0x01)
>>>> DW_AT_decl_line [DW_FORM_data1] (6)
>>>>
>>>> 0x0000004b: DW_TAG_structure_type [4] *
>>>> DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000003e] =
>>>> “S<int>")
>>>> DW_AT_byte_size [DW_FORM_data1] (0x01)
>>>> DW_AT_decl_file [DW_FORM_data1] (0x01)
>>>> DW_AT_decl_line [DW_FORM_data1] (6)
>>>>
>>>>
>>>> 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:
>>>>
>>>> DW_TAG_variable
>>>> DW_AT_type: -> DW_TAG_structure_type
>>>> DW_AT_name: S<A>
>>>> DW_AT_specification: -> DW_TAG_structure_type
>>>> DW_AT_name: S<int>
>>>> …
>>>>
>>>> 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> >.
>>>
>>> If you specify `vector<int>` in C++ do you get that instead of
>>> `vector<int, std::__1::allocator<int>>`?
>>>
>>> Yeah, I mentioned this as possibly causing problems with debuggers or other
>>> consumers, but I don't have any proof past "ooooo scary!”.
>>
>> Well, [+lldb-dev], could this confuse debuggers? :-)
>>
>> -- adrian
>>>
>>> That said, I like the idea personally :)
>>>
>>> -eric
>>>
>>>
>>>> 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.
>>>
>>> Maybe someone on cfe-dev knows a better way.
>>>
>>>>
>>>> Thoughts?
>>>>
>>>> <template-arg-typedefs.diff>
>>>>
>>>> Fred
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-comm...@cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
