So what is wrong with v3 C++

[Andrew Cagney <ac131313@cygnus.com>]

So,

[Perhaphs I should write a book about how I'm a reformed C++ programmer 
... :-)]

At the risk of ``playing manager'', I'd like to try to understand 
exactly what the problems with GDB v3.0 are.  If nothing else, I, or 
someone else, will need to document these as known bugs in the 5.1 
release notes.  Further, since C++ no longer has a maintainer, I think 
that now is probably a good time to take stock.


Anyway, to this end, I had a face to face discussion with Jim Blandy 
(Don and a few others were present and were contibuting, unfortunatly, 
neither DanB nor Michael C were around).

In that discussion, my attention was drawn to the following v3 C++ problems:


> - Dwarf 2 reader: fix constructor stuff
>   ( http://sources.redhat.com/ml/gdb/2001-06/msg00096.html )


While this has been discussed to death and causes many many failures and 
a fix involves changes to the dwarf2 reader.  I'm left wondering if:

	o	it really needs a dwarf2 rewrite

	o	compared to some of the other
		bugs, it is really that urgent

Personally, I'd be more worried about being able to single step and 
print variables correctly.



> - Virtual base classes, and their virtual functions


This, I understand is more serious.  GDB does need to be able to print 
out virtual base classes, their functions and so on.  I understand that, 
at present, it prints out bogus information.

Going by what Jim indicated, though, this in theory just involves more 
foot leather - finding the time to fill in the missing cases.  I suspect 
that who ever does do this will need very thick soles on their shoes.


> - Skipping vtable thunks, if necessary


I don't know if this was ever discussed on this list.  As I understand 
it, v3 virtual function is sometimes called via a ``thunk''.  A 
``thunk'' pulls a rabbit out of a hat (finds the correct object to pass 
to the real function) and then passes control to the real function.

At present, if GDB stepped into a thunk it would find no line info, 
treat it like a library and just skip it - oops, step into virtual 
functions via thunks doesn't work.

One proposed solution is to mimic / generalize the shared library 
mechanism so that GDB will single step through it to the real function.

I think this bug is pretty serious since, GDB will, randomly loose 
control over the target.  I certainly think it is more serious than the 
constructor problem.


> - Breakpoint work?


This one I don't remember.  There was a question if, given an arbitrary 
C++ expression, GDB could find and set a breakpoint on the correct function.


> - decode_line_1


This one has been discussed to death.  The current decode_line_1 is 
un-maintainable.  However, people, are largely living with it.


So my first question.  Are there any other serious v3 bugs?  MichaelC, 
you're probably most familar with the testsuite and what it is reporting 
as broken.

My second question.  How many of these bugs can be fixed without 
rewriting the dwarf2 reader?  My understanding is that both the virtual 
functions and the thunks bugs can.

enjoy,
	Andrew