Re: Why does C++ support in GDB suck so badly ?

[Jim Blandy <jimb@zwingli.cygnus.com>]

Gianni Mariani <gianni@mariani.ws> writes:
> It is really bad that you can't examine a simple data structure - because
> of "virtual baseclass botch" or "Value can't be converted to integer " 
> messages.

Yep.

One problem that I know happens is this:

- GDB doesn't understand namespaces, so the name of a class like
  `a::foo' gets recorded as simply `foo'.

- When you print a value of a dynamic type (i.e., one with a virtual
  table), GDB tries to check the RTTI to find its true type.  From the
  RTTI it gets the type name `a::foo'.  Unfortunately, it can't find
  this type name in its symbol table, since it appears only under `foo'.

This is kind of silly.

> I'm willing to help - but my reseach tells me that's going to be useless:
> 
> http://gcc.gnu.org/ml/gcc/2001-03/msg00475.htm
> 
> Is gdb so bad now that it needs to be thrown out and started again - in 
> C++ ?

No, I don't think so at all.

> Lack of response to my query on August 21st also shows a real lack
> of interest from the current gdb team so I'm worried.

No, we're very interested.  What we need is a volunteer who can do a
solid job of fixing things up.  The patches that have been posted so
far have a lot of problems --- they don't show much concern for corner
cases at all.  They eagerly trade correctness for speed, which I feel
is the wrong choice.

If someone with more patience for details could tackle the problem and
put together some better patches, that would be wonderful.  The right
volunteer would be someone who can read the code and figure out how
things work for themselves --- there is no thorough internals
documentation, and we have to learn the structures afresh ourselves
each time we work on them.

> Will someone on the gdb team please let us know what your plans are
> to address the lack of C++ support - even if you have none .

Like all free software projects, we depend on contributions from
capable volunteers.  Please help us make this work better.