Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain <chastain@cygnus.com>]

> >   gdb/7   cout << 1 doesn't work for c++
> This one is bogus.
> It does work.
> I poitned this out on gdb.bugs.

No.  You pointed out that it works with dwarf2.  You acknowledged
that it doesn't work with stabs.  You wrote:

  http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=23&database=gdb

  As did I, look for the posting where i showed it worked for me with
  dwarf2 on both ppc, and x86.

  It doesn't work on stabs for one of two reasons:
  ....

> >   gdb/40  C++ template functions have return types in their names
> Normal. They should.
> Look at the ABI standard.

The problem is that a template function has a name such as
"int add_two_values<int>(int, int)", whereas a normal function has a
name such as "add_two_values(int, int)".  Note the return type at the
beginning of the name.

Specifically:

  % c++filt
  _Z14add_two_valuesIiET_S0_S0_
  int add_two_values<int>(int, int)
  _Z14add_two_valuesii
  add_two_values(int, int)

This was also a problem with v2.

I'm looking at section 5.1.2 of the ABI standard, "General Structure".
The demangling grammar gets down to "unqualified source code identifier"
in about ten productions, with no reference to the function return type.
Can you quote me the part of the ABI standard that puts the return type
before the name?

> >   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 is the #1 client of the demangler so it's in our interest to check
for demangling bugs in our test suite.  That way we can find them and
push them upstream more easily.

The second reason is that libiberty/testsuite/demangle-expected has
only five cases that start with "_Z", and they are all --format=java.
So we actually have very little v3 coverage right now.

BTW, demangle.exp has 877 tests, but it covers four demangling styles:
gnu, lucid, arm, and hp.  So we are looking at 200-300 new tests,
not 900 new tests.

> >   gdb/59  static members in a base class confuse gdb
> Fixed. with a valops change i made a while ago.

I just tried this with this week's builds, and I'm getting an error:

  (gdb) p pB
  $1 = (B *) 0x8050538
  (gdb) p *pB
  Value can't be converted to integer.

Native Red Hat Linux 7, stabs, et cetera.

This is a different error than the bug reported in the PR.  Sigh.

> 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.

Yeah.  I claim that "v3 is almost better than v2".  But if v2 was
terrible, that still might not be very good.

From a scheduling point of view, JimB can fix a lot of bugs before
touching the dwarf2 reader.  From a release criteria point of view, I
just don't know how much scope work is necessary to have a shippable 5.1.

Michael