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

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

[Gianni Mariani]

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.

Are there alternatives ?

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

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.

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 .

G

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

[Andrew Cagney]

 > 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.
 >
 > Are there alternatives ?
 >
 > 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.html

Always take any thing you read with a pinch of salt.  That includes this 
e-mail.

 > Is gdb so bad now that it needs to be thrown out and started again - 
in C++ ?

Some how, i suspect that would be a bad move.  When it comes down to it, 
GDB's basic architecture must be ok - it would have to be to last 15 years!

The real problem is that there are a number of C++ bugs, some some of 
which are complex - check this mailing list for MichaelC's summary.

I don't think the complexity is comming from gdb's c++ support code, 
rather it is comming from changes needed to core core-gdb.  It is like 
hurding wild cattle through a cattle dip.  You can't get all the 
required changes through in a single hit, however with a little 
organization, some help, and some hard work, you'll soon get things 
moving in the right direction.

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

Keep in mind that people, having learnt from past mistakes, tend to only 
say something when they have both come up with a prototype of an idea 
and are willing/able to follow it through to a final implementation.

See the thread:

http://sources.redhat.com/ml/gdb/2001-06/msg00219.html

I think some people have worn themselves out trying to wressle a very 
large bull called ``name space''.  The last comment I saw, suggested 
that rewriting the dwarf2 reader is probably overkill.

If I remember right, this, and other smaller problems are always 
available for the taking.

Got your GPL assignment in order?

Andrew

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

[Gianni Mariani]

Andrew, thanks to the pointer to the thread.

So it seems there are 2 main underlying problems:

1. Dwarf 2 reader support is less than optimal
2. Proper name space support is lacking

I would have to agree that just being able to correctly
print a data structure goes a long way.

Is anyone actively managing the C++ bugs ?

What kind of help does the GDB team need ?

I'm willing to help.

G

-----Original Message-----
From: Andrew Cagney [ mailto:ac131313@cygnus.com ]
Sent: Wednesday, September 05, 2001 11:39 PM
To: Gianni Mariani
Cc: gdb@sourceware.cygnus.com
Subject: Re: Why does C++ support in GDB suck so badly ?


 > 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.
 >
 > Are there alternatives ?
 >
 > 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.html

Always take any thing you read with a pinch of salt.  That includes this
e-mail.

 > Is gdb so bad now that it needs to be thrown out and started again -
in C++ ?

Some how, i suspect that would be a bad move.  When it comes down to it,
GDB's basic architecture must be ok - it would have to be to last 15 years!

The real problem is that there are a number of C++ bugs, some some of
which are complex - check this mailing list for MichaelC's summary.

I don't think the complexity is comming from gdb's c++ support code,
rather it is comming from changes needed to core core-gdb.  It is like
hurding wild cattle through a cattle dip.  You can't get all the
required changes through in a single hit, however with a little
organization, some help, and some hard work, you'll soon get things
moving in the right direction.

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

Keep in mind that people, having learnt from past mistakes, tend to only
say something when they have both come up with a prototype of an idea
and are willing/able to follow it through to a final implementation.

See the thread:

http://sources.redhat.com/ml/gdb/2001-06/msg00219.html

I think some people have worn themselves out trying to wressle a very
large bull called ``name space''.  The last comment I saw, suggested
that rewriting the dwarf2 reader is probably overkill.

If I remember right, this, and other smaller problems are always
available for the taking.

Got your GPL assignment in order?

Andrew

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

[Jim Blandy]

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.

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

[Daniel Berlin]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> 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.
That's of course, only the start.

>
>> 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.
Quite a bit of it needs to be rewritten, however.
You need major type system work and symbol table work.
This, because of no modularization/abstraction, requires major debug
reader work, etc. 
In effect, you end up incrementally rewriting most of it.

>
>> 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.
This isn't quite true Jim.
I didn't eagerly trade correctness for speed.
Not knowingly, anyway.
The real problems with the patches is that the corner cases shouldn't
be occurring at all, and in today's well designed debuggers, they
don't.
Anytime you have to handle random corner cases at as high a level as a
simple symbol lookup, something is wrong.
Most of the problems with the patches occur because of bad (in
hindsight, of course, i'm sure they were good at the time) design
decisions in other parts of gdb, so that you have no consistency
between how gdb sees things internally across something as simple as 
debug formats.
This is where the corner cases come from. They are not inherent in the
problems the patches were meant to solve.
Not that the patches are perfect, or without their own problems.  They
had more than their share of bugs.
But you are effectively saying that GDB is sitting on a solid foundation, and
that it's just the icing on top that need work.
I don't believe this is correct.
Then again, this is why I don't use GDB anymore. I use the C++ rewrite
I started a long time ago.  I can improve it algorithmically without
having to worry about silly corner cases at a high level, and it just
works.

Other C++ debuggers i've worked on are the same way.

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

This is a bad idea, actually. You'd be better off not having someone
work on C++, and work on documenting these structures, than fixing
C++.
Where exactly do you think the problems in the patches come from?
They come from a lack of being able to assume consistency across
anything in GDB.  
For instance, one should be able to simply test with one debug format, and be
confident it will work with the other 5. 
You can't.

>
>> 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.
And good look if you do decide to contribute.
Hopefully, you'll do better than I did.

--Dan

-- 
"If you're not part of the solution, you're part of the
precipitate.
"-Steven Wright