[lldb-dev] [RFC][PATCH] Keep un-canonicalized template types in the debug information

[Frédéric Riss]

> On 12 Sep 2014, at 23:38, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: llvm-commits-bounces at cs.uiuc.edu <mailto:llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-
>> bounces at cs.uiuc.edu <mailto:bounces at cs.uiuc.edu>] On Behalf Of Frédéric Riss
>> Sent: Tuesday, September 09, 2014 6:19 AM
>> To: jingham at apple.com <mailto:jingham at apple.com>
>> Cc: lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>; llvm-commits; Greg Clayton
>> Subject: Re: [lldb-dev] [RFC][PATCH] Keep un-canonicalized template types
>> in the debug information
>> 
>> 
>>> On 09 Sep 2014, at 00:01, jingham at apple.com wrote:
>>> 
>>> From the debugger's standpoint, the functional concern is that if you do
>> something more real, like:
>>> 
>>> typedef int A;
>>> template <typename T>
>>> struct S
>>> {
>>> T my_t;
>>> };
>>> 
>>> 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.
>>> 
>>> However, it would be really odd to see:
>>> 
>>> (lldb) expr -T -- my_s
>>> (S<int>) $1 = {
>>> (A) my_t = 5
>>> }
>>> 
>>> instead of:
>>> 
>>> (lldb) expr -T -- my_s
>>> (S<A>) $1 = {
>>> (A) my_t = 5
>>> }
>>> 
>>> 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.
>> 
>> OK, we get this wrong today. I’ll try to look into it.
>> 
>> 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 :
>> 
>> 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>
>> 
>> 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.
>> 
>> Fred
> 
> Why introduce the extra typedef? S<A> should have a template parameter
> entry pointing to A which points to int.  The info should all be there
> without any extra stuff.  Or if you think something is missing, please
> provide a more complete example.

The template type information is stored in 2 places:
 - In the template argument DIEs that you mention (I didn’t touch to this one)
 - In the name of the template type (this is the one the patch is modifying)

It is my understanding that the debugger will use the latter more than the template argument DIE. Thus my goal is to register both S<A> and S<int> as valid types so that we don’t lose any information compared to what was there before.

Fred

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140915/e09f2082/attachment.html>