From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Elizabeth Chastain To: ac131313@cygnus.com, gdb@sources.redhat.com Subject: Re: So what is wrong with v3 C++ Date: Thu, 28 Jun 2001 18:12:00 -0000 Message-id: <200106290112.SAA29748@stanley.cygnus.com> X-SW-Source: 2001-06/msg00220.html Here are the open PR's: gdb/7 cout << 1 doesn't work for c++ gdb/18 gdb can't parse "info func operator*" or "info func operator\*" gdb/19 gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7 gdb/27 ptype shows duplicate constructors and destructors gdb/33 name matching on template names is sensitive to white space gdb/34 g++ v3 functions show as "inheritance2() ()" gdb/39 C++ constructors show bogus return type gdb/40 C++ template functions have return types in their names gdb/41 testsuite/gdb.c++/demangle.exp needs v3 coverage gdb/57 nested classes incorrectly printing gdb/59 static members in a base class confuse gdb gdb/60 GDB has problems with C++ symbols As I've talked about with JimB, PR gdb/27 requires new design in gdb. The issue is that gcc takes one source function (a constructor or a destructor) and emits two or three object code functions for it. This is new in g++ v3, and as far as I know, gdb has never had machinery to handle anything like this. All the rest of the PR's are simply bugs. Some of the template stuff and namespace stuff may require new design. Probably every case that is broken in v3 was already broken in v2. Pointers-to-members probably don't work. There is a test script gdb.c++/member-ptr.exp that is disabled with the following comment: # Nearly all of these tests fail when compiled with G++, so just give up # until GDB gets enhanced. -sts 1999-06-22 Here are the bugs that I haven't filed PR's on yet. I'll just bite the bullet and file some PR's tonight. function call with reference parameter fails in gdb.c++/classes.exp fails in both v2.95.3 and v3pre When the test script calls a function by hand, and the function has a reference parameter, the inferior program gets a SIGSEGV. user accesses ambiguous base fails in gdb.c++/inherit.exp fails in both v2.95.3 and v3pre The program under test has a non-virtual base class which appears several times (B:A and C:A and D:B,C so D has two A's). The debugger when the user references a member such as "d::a", gdb should say that this is ambiguous. Instead, gdb uses the first one that it finds. gdb value for some arguments at beginning of function fails in gdb.c++/overload.exp passes in v2.95.3, fails in v3pre Argument values are incorrect when calling a function with an arg of type short, unsigned short, long, or unsigned long. user sets breakpoint on template class ctor/dtor fails in gdb.c++/templates.exp results lost for v.29.3, fails in v3pre The test script attempts to set breakpoints on "T5::T5" and "T5::~T5". gdb fails to find these functions. > 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. I think so too. There's a big issue with finding and using the virtual base pointers properly. As I understand it, Jim's going to rewrite this code. Then if the code has problems, we will: . check the assembly code of the program-under-test against the Intel spec. If the assembly code does not conform, file an upstream PR against gcc. . if the assembly code does conform, debug the new v3 code that implements stuff like baseclass_offset. Another way to look it: I don't think any of the *new* v3 bugs are in the dwarf2 reader. Michael