From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: GDB Discussion Subject: So what is wrong with v3 C++ Date: Thu, 28 Jun 2001 16:28:00 -0000 Message-id: <3B3BBD90.8070601@cygnus.com> X-SW-Source: 2001-06/msg00219.html 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