Re: So what is wrong with v3 C++

[Daniel Berlin <dan at cgsoftware dot com>]

Michael Elizabeth Chastain <chastain@cygnus.com> 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