This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory

On 12/11/06, Daniel Jacobowitz <> wrote:
On Mon, Dec 11, 2006 at 05:03:18PM +0100, Michael Matz wrote:
> Hi,
> On Mon, 11 Dec 2006, Daniel Jacobowitz wrote:
> > On Mon, Dec 11, 2006 at 04:50:41PM +0100, Richard Guenther wrote:
> > > With using mangled names (which would lead to so much smaller debug info)
> > > we'd have to fix gdb of course.  But maybe stage1 of gcc 4.3 is a good
> > > amount ahead of time to let gdb folks sort this out themselves...
> >
> > Maybe if someone could write up a coherent explanation of what you want
> > to change...
> The change in debug info would be that DW_AT_name would not necessarily
> contain a nice user printable name anymore (which right now is generated
> by gcc via the diagnostic machinery) but would sometimes contain a mangled
> name (i.e. recognizable by being prefixed with "_Z").  If gdb could handle
> that (i.e. before showing any name try to demangle it and see if that
> worked) all would be well.  DW_AT_linkage_name would not be touched by
> that.
> There will be differences between the current user friendly name and the
> demangled version (for instance some scopes are left out in the current
> variant), but IMHO that's more consistent.

No way, please don't do this.  DW_AT_name is supposed to be the type
name from the source language.

14 Identifier Names

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.

You are aware that, in it's current form for the testcase in PR29433 the largest such string is 2MB in size? Also the specification "whose value is a string representing the name as it appears in the source program" is not exactly clear to me. Would gdb prefer "std::string" or "string" or "std::basic_string" or even "basic_string<char,std::char_traits<char>,std::allocator<char> >" (which is what we currently have).

I believe that gdb could be more friendly in printing templated types
if they are presented in a better to machine-analyze manner, like in
mangled form rather than "arbitraryly" choosing one of the above.

I also note that we have sort-of duplicate information like for example

<2><2358>: Abbrev Number: 34 (DW_TAG_subprogram)
    DW_AT_sibling     : <23a5>
    DW_AT_external    : 1
    DW_AT_name        : address
    DW_AT_decl_file   : 25
    DW_AT_decl_line   : 75
    DW_AT_MIPS_linkage_name: _ZNK9__gnu_cxx13new_allocatorIcE7addressERc
    DW_AT_type        : <763>
    DW_AT_declaration : 1

where DW_AT_name is a very simplified form of DW_AT_MIPS_linkage_name.
I suppose we couldn't use the template
base name for DW_AT_name for DW_TAG_structure_type also, adding
a mangled name as Michael suggests for DW_AT_MIPS_linkage_name?
So that we get instead of

<2><54a>: Abbrev Number: 13 (DW_TAG_structure_type)
    DW_AT_sibling     : <5ce>
    DW_AT_name        :
basic_string<char,std::char_traits<char>,std::allocator<char> >
    DW_AT_declaration : 1

we get

<2><54a>: Abbrev Number: 13 (DW_TAG_structure_type)
    DW_AT_sibling     : <5ce>
    DW_AT_name        : string
    DW_AT_declaration : 1
    DW_AT_MIPS_linkage_name : _ZNSsC1Ev

(just to use the constructor mangled name as mangling for a type)

The question is where gdb uses the DW_AT_name in DW_TAG_structure_type
specifiers - I couldn't find an entry in the gdb testsuite that looks
at it.  Most
of the other DW_AT_names are just base-names.  In fact we currently
generate an "elaborated" DW_AT_name only in the case

     /* Specializations have already had their names set up in
        lookup_template_class.  */
     tree tmpl = most_general_template (CLASSTYPE_TI_TEMPLATE (t));

     /* For non-primary templates, the template parameters are
        implicit from their surrounding context.  */
     if (PRIMARY_TEMPLATE_P (tmpl))
         tree name = DECL_NAME (tmpl);
         char *mangled_name = mangle_class_name_for_template
           (IDENTIFIER_POINTER (name),
            CLASSTYPE_TI_ARGS (t));
         tree id = get_identifier (mangled_name);
         IDENTIFIER_TEMPLATE (id) = name;
         return id;

calls mangle_class_name_for_template.  I cannot really decipher this
condition to a specification on the kind of types we would do so, but
maybe Mark has an idea in what cases we actually use the elaborated


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]