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 Tue, 12 Dec 2006, Mark Mitchell wrote:

> > template <typename T> class X {};
> > template <typename T> class Y {};
> > template <typename T> class Z {};
> > template <typename T, typename H=X<T>, typename I=Y<T>, typename J=Z<T>>
> > class A {};
> > template <typename T, typename H=A<T>, typename I=A<A<T>>>
> > class B {};
> > B<int> an_object;
> > 
> > I wouldn't like to see the type of 'an_object' in the debugger to be shown 
> > as (and I cite):
> > 
> > "B<int,A<int, X<int>, Y<int>, Z<int> >,A<A<int, X<int>, Y<int>,
> > Z<int> >, X<A<int, X<int>, Y<int>, Z<int> > >, Y<A<int, X<int>, Y<int>, 
> > Z<int> > >, Z<A<int, X<int>, Y<int>, Z<int> > > > >"
> One way to solve this is for the debugger to print this as:
>   B<#1, A<#1>, A<A<#1> > > with #1 = int

I'm aware of that notation, but debugging != printing diagnostics.

For simple printing diagnostics the above may be enough (though I still 
would prefer to read B<int>, as it is completely descriptive (because that 
is the form in the sources, and if it weren't completely descriptive the 
sources were illformed)).  But for debugging this form simply doesn't 
work.  How would you try to enter a breakpoint in the ctor of such type?  
Would you be really willing to (try to) enter the above form?

It also interacts badly with cmdline completion.

> But, I certainly think all the template arguments should be in the debug 
> information.

In principle I agree that this would be the ideal solution.  But I also 
claim that this currently leads to intractable practical problems in 
debugging C++ programs involving heavy template use with gdb (or any other 
debugger who looks at the current DW_AT_name for them).  Ask Richard about 
debugging tramp3D with gdb.  It's basically a joke.

So for the above ideal world quite some work would be needed: 1) make gcc 
not emit hand-crafted strings for templates, but more in the line of the 
suggestion of this thread as separate DIEs per template arg, and 2) make 
gdb accept that.

The work for (1) seems to be doable, but I'm unsure how much work (2) 
would be.  I guess much.  Again one needs to consider cmdline completion 
and the like (and keep the memory use of gdb in mind).

> For example, it's reasonable for the user to ask for things like "sizeof 
> (I)" within the scope of B, and it would be nice to answer that.
> The debugging information should be complete; all throttling/formatting 
> can be done in the debugger.

I agree also here.  But currently that isn't the case anyway; it is sort 
of complete, but impossible to throttle to managable levels.

> > Further, I would stop at typedefs.  Given the above decls, and adding 
> > this:
> > 
> > typedef B<float> new_B;
> > B<new_B> another_object;
> All of the issues you're raising here apply just as well to the 
> compiler's own error messages.

See above why error messages are only a subset of what is needed for 

> In general, I'd suggest that we make G++ to do whatever we think best, 
> and then have GDB copy that.  This particular case is a bit tricky: 
> user's sometimes want to know if B<typedef_1> and B<typedef_2> are the 
> same type -- and it's not very easy to see that in the format you 
> suggest.

You aren't claiming that it's easier when you do "ptype a", "ptype b" and 
get two 100KB strings as answer that this helps you to determine if the 
two types are the same, are you?  Again in the abstract I could agree with 
you, but I would suggest that if this is what users need, that they look 
at the mangled name to determine sameness.  Or better yet, that the 
debugger would have a mean of comparing two types.

This also enters the realm of language semantics anyway, as the question 
when two types are the same depends on it.  So comparing two strings given 
by "ptype" isn't necessarily what you look for anyway.

> So, some people argue strongly for showing typedefs; others argue 
> strongly against it. Ideally, the debug information would show the 
> typedef, and the debugger could decide whether to show the typedef name 
> or the type referred to by the typedef.

Yes, ideally.  But gdb hackers are so rare that I wouldn't hold my breath.  
Let's assume that we won't easily get support for fancy DWARF annotation 
in gdb soon, i.e. that for now we have to live with single DW_AT_name 
stuff.  Would you prefer us continue emitting the huge strings or smaller 
versions (mangled or cutdown by the rules I wrote in my other mail)?


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