This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

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


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


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