Re: So what is wrong with v3 C++

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

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<int>::T5"
    and "T5<int>::~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