This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: So what is wrong with v3 C++
- To: ac131313 at cygnus dot com, gdb at sources dot redhat dot com
- Subject: Re: So what is wrong with v3 C++
- From: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Date: Thu, 28 Jun 2001 18:12:23 -0700
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