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

I'm so glad you wrote this :-)

I agree with most of it, see below.  However, there's one caveat that
occurred to me while writing it.  We don't get to change the demangled
names of member functions.  GDB - and the user - may get quite confused
if you have "class A<x>" and method "A<x,std::basic_string<...>>::bar(int)".

I'm sure we can make it work somehow.  But the GDB surgery involved
would be immense.

On Tue, Dec 12, 2006 at 06:45:33PM +0100, Michael Matz wrote:
> For starters I wouldn't output default args.  I.e. given these decls:

Sounds quite sensible to me, for the current DW_AT_name.  For
DW_TAG_template_type_parameter, there's no currently defined way to
represent this, but one seems obvious: DW_AT_artificial.

It's still desirable to represent them, so that in the debugger one
can say "ptype T" in the scope of the class and get the type of the
default parameter.

> That is just kafkaesque.  I would accept "B<int>" or "B" (I would prefer 
> for the debugger to give me both possibilities).  I wouldn't like to have 
> to store the above abomination into debug infos as I can foresee no 
> sensible use for that which justifies the space bloat (in object files 
> _and_ debugger runtime memory use).

I think my example above is a sensible use.  Besides, if you store it
as DIEs, most of the items in your example can be shared - so the size
of the debug info would actually be considerably less than the
pretty-printed version.

> Further I wouldn't transitively elaborate the type, but only look at depth 
> 1 (think template meta programming).  I can see uses for someone who might 
> want a larger depth (though I'm completely convinced that no human wants 
> to really look at type names nested deeper than say 10), so that's more 
> discussable.

This is a hiding-information issue, so I'm less inclined to agree.

> Further, I would stop at typedefs.

I'd love this.  Please.  Please.  Same for the DIE format we eventually
want; it should point to the DW_TAG_typedef.

> [I seem to remember that sometimes even now DW_AT_name isn't unambiguous 
> anyway, sometimes scopes are missing (certainly when declared and used 
> inside the same namespace, but that's natural, and can be seen from the 
> nesting context of the DIEs), but I may misremember.]

The scopes should be sufficient in current GDB - with a possible
exception for anonymous namespaces which make everything more

Daniel Jacobowitz

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