This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
So what is wrong with v3 C++
- To: GDB Discussion <gdb at sources dot redhat dot com>
- Subject: So what is wrong with v3 C++
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 28 Jun 2001 19:28:16 -0400
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