From dodji@redhat.com  Tue Jun  7 14:12:21 2011
From: dodji@redhat.com (Dodji Seketeli)
Date: Tue, 07 Jun 2011 16:12:21 +0200
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
Message-ID: <m3ipshd92y.fsf@redhat.com>

Hello,

This is a follow-up to an RFC that I first sent on 20 October 2009 to
which nobody replied.

Now that G++ emits DW_AT_template_*_parameter* DIEs and that GDB
consumes that debugging information, it appears that the content of
the DW_AT_name attribute of a template instantiation could use some
clarifications.

Consider this short c++ code snippet:

~=~
template<class T>
struct S {};

S<int> s;
~=~

In quite a number of implementations - including G++ - The DW_TAG_class_type
DIE representing S<int> has a DW_AT_name that is set to the template-id string
"S<int>" today.

But then if the DW_TAG_class_type DIE has a
DW_TAG_template_type_parameter child DIE, setting the DW_AT_name
attribute of that DW_TAG_class_type DIE to the template-id "S<int>"
becomes redundant and slows down debug info consumers.  It would be more
orthogonal and efficient for consumers to just set that attribute to the
template name string "S" as the template parameters part can be
synthesized by the debugger from the DW_TAG_template_type_parameter DIE.

I believe the DWARF specification does not clearly states this.  In the
DWARF 4 version, neither "3.3.7 Function Template Instantiation" nor
"5.5.8 Class Template Instantiation" precisely states what the
DW_AT_name attribute of the template instantiation should contain.

Therefore, I would like to propose the following amendments to the two
sections mentionned above.

In "5.5.8 Class Template Instantiation", the paragraph that currently
reads:

    A class template instantiation is represented by a debugging
    information entry with the tag DW_TAG_class_type,
    DW_TAG_structure_type or DW_TAG_union_type. With five exceptions,
    such an entry will contain the same attributes and have the same
    types of child entries as would an entry for a class type defined
    explicitly using the instantiation types and values. The exceptions
    are:

would be changed into [note how the "five" is changed into "six"]:

    A class template instantiation is represented by a debugging
    information entry with the tag DW_TAG_class_type,
    DW_TAG_structure_type or DW_TAG_union_type. With six exceptions,
    such an entry will contain the same attributes and have the same
    types of child entries as would an entry for a class type defined
    explicitly using the instantiation types and values. The exceptions
    are:

A sixth exception would then be added and it would read:

    The value of the DW_AT_name attribute of the entry representing the
    class template instantiation is a null terminated string that
    contains the simple name of the template, without any template
    argument.

Similarly, in section "3.3.7 Function Template Instantiation", the
paragraph that currently reads:

    A template instantiation is represented by a debugging information
    entry with the tag DW_TAG_subprogram. With four exceptions, such an
    entry will contain the same attributes and will have the same types
    of child entries as would an entry for a subroutine defined
    explicitly using the instantiation types. The exceptions are:

would be changed into [note how the "four" is changed in to "five"]:

    A template instantiation is represented by a debugging information
    entry with the tag DW_TAG_subprogram. With five exceptions, such an
    entry will contain the same attributes and will have the same types
    of child entries as would an entry for a subroutine defined
    explicitly using the instantiation types. The exceptions are:

A fifth exception would then be added and it would read:

    The value of the DW_AT_name attribute of the entry representing the
    function template instantiation is a null terminated string that
    contains the simple name of the template, without any template
    argument.

Thoughts?

-- 
		Dodji



From jason@redhat.com  Tue Jun  7 14:31:45 2011
From: jason@redhat.com (Jason Merrill)
Date: Tue, 07 Jun 2011 10:31:45 -0400
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <m3ipshd92y.fsf@redhat.com>
References: <m3ipshd92y.fsf@redhat.com>
Message-ID: <4DEE3651.9040809@redhat.com>

I don't think these are exceptions; 2.15 says,

Any debugging information entry representing a program entity that has 
been given a name may have a DW_AT_name attribute, whose value is a 
string representing the name as it appears in the source program.

The name of a class template specialization is the name of the template; 
the template-id is a way of specifying a particular specialization, but 
it isn't a name.

I do think it makes sense to change the sections you mention, but I'd 
add the text as a clarifying note in italics rather than call it an 
exception.

Jason



From dodji@redhat.com  Tue Jun  7 14:56:10 2011
From: dodji@redhat.com (Dodji Seketeli)
Date: Tue, 07 Jun 2011 16:56:10 +0200
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <4DEE3651.9040809@redhat.com> (Jason Merrill's message of "Tue,
	07 Jun 2011 10:31:45 -0400")
References: <m3ipshd92y.fsf@redhat.com> <4DEE3651.9040809@redhat.com>
Message-ID: <m3aadtd71x.fsf@redhat.com>

Jason Merrill <jason at redhat.com> writes:

> I do think it makes sense to change the sections you mention, but I'd
> add the text as a clarifying note in italics rather than call it an
> exception.

OK.  I have thus amended the proposal as below.

In section "5.5.8 Class Template Instantiation", the following
clarifying note in italics would be added:

    The value of the DW_AT_name attribute of the entry representing the
    class template instantiation is a null terminated string that contains
    the simple name of the template, without any template argument.

In section "3.3.7 Function Template Instantiation", this similar
clarifying note in italics would be added:

    The value of the DW_AT_name attribute of the entry representing
    the function template instantiation is a null terminated string
    that contains the simple name of the template, without any
    template argument.

Thanks.

-- 
		Dodji



From jason@redhat.com  Tue Jun  7 15:06:02 2011
From: jason@redhat.com (Jason Merrill)
Date: Tue, 07 Jun 2011 11:06:02 -0400
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <m3aadtd71x.fsf@redhat.com>
References: <m3ipshd92y.fsf@redhat.com> <4DEE3651.9040809@redhat.com>
	<m3aadtd71x.fsf@redhat.com>
Message-ID: <4DEE3E5A.90006@redhat.com>

On 06/07/2011 10:56 AM, Dodji Seketeli wrote:
>      The value of the DW_AT_name attribute of the entry representing the
>      class template instantiation is a null terminated string that contains
>      the simple name of the template, without any template argument.

I don't think we need to specify "null terminated string" here, that's 
true of all DW_AT_names.

Jason



From eager@eagercon.com  Tue Jun  7 15:14:43 2011
From: eager@eagercon.com (Michael Eager)
Date: Tue, 07 Jun 2011 08:14:43 -0700
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
 instantiations
In-Reply-To: <m3aadtd71x.fsf@redhat.com>
References: <m3ipshd92y.fsf@redhat.com> <4DEE3651.9040809@redhat.com>
	<m3aadtd71x.fsf@redhat.com>
Message-ID: <4DEE4063.5090704@eagercon.com>

On 06/07/2011 07:56 AM, Dodji Seketeli wrote:
> Jason Merrill<jason at redhat.com>  writes:
>
>> I do think it makes sense to change the sections you mention, but I'd
>> add the text as a clarifying note in italics rather than call it an
>> exception.
>
> OK.  I have thus amended the proposal as below.
>
> In section "5.5.8 Class Template Instantiation", the following
> clarifying note in italics would be added:
>
>      The value of the DW_AT_name attribute of the entry representing the
>      class template instantiation is a null terminated string that contains
>      the simple name of the template, without any template argument.
>
> In section "3.3.7 Function Template Instantiation", this similar
> clarifying note in italics would be added:
>
>      The value of the DW_AT_name attribute of the entry representing
>      the function template instantiation is a null terminated string
>      that contains the simple name of the template, without any
>      template argument.

When this proposal is fully cooked, please submit it at
http://dwarfstd.org/Comment.php.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



From dodji@redhat.com  Tue Jun  7 15:27:17 2011
From: dodji@redhat.com (Dodji Seketeli)
Date: Tue, 07 Jun 2011 17:27:17 +0200
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <4DEE3E5A.90006@redhat.com> (Jason Merrill's message of "Tue, 07
	Jun 2011 11:06:02 -0400")
References: <m3ipshd92y.fsf@redhat.com> <4DEE3651.9040809@redhat.com>
	<m3aadtd71x.fsf@redhat.com> <4DEE3E5A.90006@redhat.com>
Message-ID: <m339jld5m2.fsf@redhat.com>

Jason Merrill <jason at redhat.com> writes:

> I don't think we need to specify "null terminated string" here, that's
> true of all DW_AT_names.

Right.  Here is an updated proposal.

In section "5.5.8 Class Template Instantiation", the following clarifying note in
italics would be added:

    The value of the DW_AT_name attribute of the entry representing the
    class template instantiation contains the simple name of the
    template, without any template argument.

In section "3.3.7 Function Template Instantiation", this similar
clarifying note in italics would be added:

    The value of the DW_AT_name attribute of the entry representing the
    function template instantiation contains the simple name of the
    template, without any template argument.

-- 
		Dodji



From jason@redhat.com  Tue Jun  7 15:34:35 2011
From: jason@redhat.com (Jason Merrill)
Date: Tue, 07 Jun 2011 11:34:35 -0400
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <m339jld5m2.fsf@redhat.com>
References: <m3ipshd92y.fsf@redhat.com>
	<4DEE3651.9040809@redhat.com>	<m3aadtd71x.fsf@redhat.com>
	<4DEE3E5A.90006@redhat.com> <m339jld5m2.fsf@redhat.com>
Message-ID: <4DEE450B.8040803@redhat.com>

Looks good to me.

Jason



From dodji@redhat.com  Tue Jun  7 15:51:24 2011
From: dodji@redhat.com (Dodji Seketeli)
Date: Tue, 07 Jun 2011 17:51:24 +0200
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <4DEE4063.5090704@eagercon.com> (Michael Eager's message of "Tue, 
	07 Jun 2011 08:14:43 -0700")
References: <m3ipshd92y.fsf@redhat.com> <4DEE3651.9040809@redhat.com>
	<m3aadtd71x.fsf@redhat.com> <4DEE4063.5090704@eagercon.com>
Message-ID: <m3tyc1bpxf.fsf@redhat.com>

Michael Eager <eager at eagercon.com> writes:

> When this proposal is fully cooked, please submit it at
> http://dwarfstd.org/Comment.php.

I'll wait a couple of days and submit it there then.

Thanks.

-- 
		Dodji



From dodji@redhat.com  Tue Jun  7 20:54:11 2011
From: dodji@redhat.com (Dodji Seketeli)
Date: Tue, 07 Jun 2011 22:54:11 +0200
Subject: [Dwarf-Discuss] [PING] [RFC] content of DW_AT_name for template
	instantiations
In-Reply-To: <m339jld5m2.fsf@redhat.com> (Dodji Seketeli's message of "Tue, 07
	Jun 2011 17:27:17 +0200")
References: <m3ipshd92y.fsf@redhat.com> <4DEE3651.9040809@redhat.com>
	<m3aadtd71x.fsf@redhat.com> <4DEE3E5A.90006@redhat.com>
	<m339jld5m2.fsf@redhat.com>
Message-ID: <m3tyc19xcc.fsf@redhat.com>

Keith Seitz noticed that I should probably and a "(s)" to "argument" in
"without any template argument(s)".  So here is an updated proposal.

In section "5.5.8 Class Template Instantiation", the following
clarifying note in italics would be added:

    The value of the DW_AT_name attribute of the entry representing the
    class template instantiation contains the simple name of the
    template, without any template argument(s).

In section "3.3.7 Function Template Instantiation", this similar
clarifying note in italics would be added:

    The value of the DW_AT_name attribute of the entry representing the
    function template instantiation contains the simple name of the
    template, without any template argument(s).

-- 
		Dodji



From david.moore@intel.com  Thu Jun  9 14:56:42 2011
From: david.moore@intel.com (Moore, David)
Date: Thu, 9 Jun 2011 07:56:42 -0700
Subject: [Dwarf-Discuss] content of DW_AT_name for template
In-Reply-To: <mailman.1.1307467196.26932.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
References: <mailman.1.1307467196.26932.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
Message-ID: <3BA20DF9B35F384F8B7395B001EC3FB3C8369985@azsmsx507.amr.corp.intel.com>

Issue 1: 

I assume this is being proposed as a "clarification" for Dwarf-4 rather than a change for Dwarf-5. Really it impacts previous versions too so all Dwarf emitters are potentially impacted.

Given the impact, I don't find the rational for this change sufficiently compelling. If I am understanding correctly, the rational is "to speed up dwarf read times for the debugger". I paraphrase, but I think that captures the intent - if it doesn't, I have missed something. 

So, it is an optimization that renders currently conforming implementations non-conforming for the sake of a performance improvement. The spec may be unclear at present, so you can argue it is just a clarification, but once you clarify it, it renders some reasonable interpretations, including the one I would choose, non-conforming.

In addition, given that names in C++ can be astonishingly long, using indirect strings seems like a good idea in general. In that case I don't think there is much of a performance improvement. If you lay down many S<int>'s you only have to read the full name once if you are using indirect strings while if you are clever enough to merge them, you only have to read it once anyway. [1]

So if this is to be added as a clarification to Dwarf-4 I think it should be as a "may" (be the simple name) rather than "shall" be the simple name. In dwarf-5 it could then be firmed up (made a "shall"). By then we would hopefully have some implementation experience (of the form, what broke and how hard was it to fix)

The main effect of "may" is that consumers of the dwarf could be expected to still handle the long form of the name which, if they also supported the short form, they could presumably do by throwing away everything from the first "<" onwards.

In addition, the emitter of the dwarf could institute an option to emit one form or the other so that a consumer which was not capable of reconstituting the full name could be handed dwarf it could eat.

Issue 2: 

Do you want a fully qualified name rather than a simple name? You did not mention how to make this part of the reconstruction of the full name and, although I have not spent more than ten minutes looking at the problem, I am not seeing how to do it. 



[1] In Dwarf-5, we should perhaps think about creating a way to compose indirect strings so that we can merge long common prefixes from names. This is off-topic but I wanted to get the thought on the record while it was in my head.





From jason@redhat.com  Thu Jun  9 15:21:08 2011
From: jason@redhat.com (Jason Merrill)
Date: Thu, 09 Jun 2011 11:21:08 -0400
Subject: [Dwarf-Discuss] content of DW_AT_name for template
In-Reply-To: <3BA20DF9B35F384F8B7395B001EC3FB3C8369985@azsmsx507.amr.corp.intel.com>
References: <mailman.1.1307467196.26932.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
	<3BA20DF9B35F384F8B7395B001EC3FB3C8369985@azsmsx507.amr.corp.intel.com>
Message-ID: <4DF0E4E4.6030304@redhat.com>

On 06/09/2011 10:56 AM, Moore, David wrote:
> So if this is to be added as a clarification to Dwarf-4 I think it should be as a "may" (be the simple name) rather than "shall" be the simple name.

That makes sense.

> Do you want a fully qualified name rather than a simple name?

I wouldn't think so.  We don't use fully-qualified names for other 
entities.  But I think it makes sense to drop the word "simple" here.

Jason



