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

[Mark Mitchell <mark at codesourcery dot com>]

Michael Matz wrote:

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

For big C++ programs, no amount of eliding default arguments is going to
get you nice compact type names.  That's why C++ programs are full of
"typedef typename X::Y Z" stuff.  I think that what you really want to
say for breakpoints is something like:

  b X::Y::Z::C

where X is a class, Y is a typedef (declared in X), Z is a typedef
(declared in Y), and C is the actual name of the class.  For example, I
expecting that Z might be:

  typedef C<...> Z;

The key point, echoing what you and Daniel have been saying, is that you
need to be able to leverage the typedefs the programmer already has.
Breakpoints are easier than printing the types of things, since you can
accept multiple names for the same function as breakpoints, but when
printing a type who have to pick one way of printing it.  No
type-printing heuristic is ever going to be perfect.

> debugger who looks at the current DW_AT_name for them).  Ask Richard about 
> debugging tramp3D with gdb.  It's basically a joke.

We know a fair amount about debugging big C++ programs.  Remember who
lead POOMA development for several years? :-)

Nobody is arguing that DW_AT_name should be the huge string for the long
term.  However, I would argue that it should stay that huge string until
we add the template arguments to debug info, and until GDB understands
that information.  I would consider dropping default arguments.  But,
mangled names are not in the spirit of DWARF, and dropping the template
argument information completely is taking away critical information.

Even using typedefs and dropping default arguments isn't a no-brainer,
because it's reasonable to do something like:

  # I have a function compiled into my program called "my_typeid" which
  # returns __cxa_demangle (typeid (x).name())
  (gdb) print my_typeid (x)
  C<....>
  (gdb) b C<....>::C

If GDB can't tell that the giant string coming from typeid isn't the
same as the one it has for the type, my breakpoint won't work.  This
probably already doesn't work, due to differences between how G++
formats the type names and how the demangler demangles them -- but
that's probably a bug.  The point is that GDB ought to be able to
understand all of these different names for a type, and treat them as
the same -- but to do that, it needs to know a fair bit about C++, and
not just treat type names as literal strings.

If you want better GDB support for C++ with templates, I think emitting
the template arguments is a first step.  Then, I think some work on GDB
is essential.  GDB ought to be able to handle these various
relationships, and there's no way around giving it some smarts to do
that.  We (CodeSourcery) would certainly be interested in such a project.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713