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

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 12 Dec 2006, Daniel Jacobowitz wrote:

> What else do you expect to happen?

Since you asked ;-) :

For starters I wouldn't output default args.  I.e. given these decls:

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> > > > >"

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).

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.

Further, I would stop at typedefs.  Given the above decls, and adding 
this:

typedef B<float> new_B;
B<new_B> another_object;

The type of 'another_object' starts with (I cite again from readelf -wi):

"B<B<float, A<float, X<float>, Y<float>, Z<float> >, A<A<float, X<float>, 
Y<float>, Z<float> >, X<A<float, X<float>, Y<float>, Z<float> > >, 
Y<A<float, X<float>, Y<float>, Z<float> > >, Z<A<float, X<float>, 
Y<float>, Z<float> > > > >,A<B<float, A<float, X<float>, Y<float>, 
Z<float> >, A<A<float, X<float>, Y<float>, Z<float> >, X<A<float, 
X<float>, Y<float>, Z<float> > >, Y<A<float, X<float>, Y<float>, Z<float> 
> >, Z<A<float, X<float>, Y<float>, "

and continues for another 4440 characters.  I would want "B<new_B>".

What we currently output is less than useless, it actively hinders 
debugging larger C++ programs.  Let it be a sign that I actually sometimes 
even _wished_ for the debugger to print out mangled names.  They certainly 
are easier to read and compare via copy&paste.  For instance the mangled 
name for the above 5KB string is just two lines.  Not very good 
("B<new_B>" still is nicer) but much better in this case.

> Sure, we could throttle the debug info and omit the name.  But that's 
> much like reintroducing a 63 character (or however many) limit on unique 
> identifiers; the debug info wouldn't unambiguously identify the source 
> type.

I claim that for all practical matters a 5000 character string doesn't 
identify anything at all, it's just character salad :-)  Sometimes limits 
are good, one can make it configurable if one absolutely must, but it 
seems more sensible to use a compressed form of the name which debuggers 
then can decompress in various ways.  A mangled representation is a 
natural choice, but a DIE based seems to work too (though more complex to 
implement).

[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.]


Ciao,
Michael.