From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Michael Elizabeth Chastain Cc: ac131313@cygnus.com, gdb@sources.redhat.com Subject: Re: So what is wrong with v3 C++ Date: Thu, 28 Jun 2001 19:06:00 -0000 Message-id: <87u210kpkj.fsf@cgsoftware.com> References: <200106290112.SAA29748@stanley.cygnus.com> X-SW-Source: 2001-06/msg00223.html Michael Elizabeth Chastain writes: > Here are the open PR's: > > gdb/7 cout << 1 doesn't work for c++ This one is bogus. It does work. I poitned this out on gdb.bugs. > gdb/18 gdb can't parse "info func operator*" or "info func > operator\*" parser bug. > gdb/19 gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7 demangler bug. > gdb/27 ptype shows duplicate constructors and destructors Needs redesign of parts of gdb. > gdb/33 name matching on template names is sensitive to white > space > gdb/34 g++ v3 functions show as "inheritance2() ()" Demangler bug. > gdb/39 C++ constructors show bogus return type Scoping bug. > gdb/40 C++ template functions have return types in their names Normal. They should. Look at the ABI standard. > gdb/41 testsuite/gdb.c++/demangle.exp needs v3 coverage libiberty already has demangler coverage for the demangler, why do we need it in gdb as well? > gdb/57 nested classes incorrectly printing Scoping bug. > gdb/59 static members in a base class confuse gdb Fixed. with a valops change i made a while ago. > gdb/60 GDB has problems with C++ symbols Scoping bug. > > 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. > Yes. > > 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. I've got this one fixed. Patch forthcoming. It took me a while to take HP's code to do this, and make it look reasonable. :) > > Another way to look it: I don't think any of the *new* v3 bugs are in > the dwarf2 reader. Sure. I'll give you that. These bugs were always there, v3 just exposes them a heck of a lot more. They used to be hard to see, and users would occasionally complain. Now it's right in their face, almost any time they use the standard library. Anything marked scoping bug requires the dwarf2 reader rewrite. You could hack the stabs reader to be better, but it would take some work. And you can't actually fix the real cause. :( > Michael -- "I used to be a waiter, but I was fired for clearing tables. I was clearing them for take off. I had them all lined up outside. People thought it was an outdoor cafe. I said, "No, these are leaving at 3." They were going to fire me anyway, because I told them I thought they should put the wrapper on the inside of the straw since that's the part you don't want to get dirty. "-Steven Wright