This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb.c++ failures

On Thu, Jan 10, 2002 at 01:17:56PM +0000, Jason Merrill wrote:
> I've been looking at the various C++ debugging failures on
> i686-pc-linux-gnu using dwarf2.  Here's my analysis:

Already answered some of these, here's a few more...

>   classes.exp: dwarf2 doesn't provide mangled names for abstract
>    constructors, and there is a difference of opinion between the
>    demangler and c-typeprint.c as to whether the type should be written "A
>    const &" or "const A &".  The demangler always puts the cv-qualifier
>    after the type it affects, whereas gdb puts it in front whenever that
>    would have the correct meaning.  Either one could be changed to match
>    the other, or the testcase could be modified to accept either form.
>    Thoughts?

The demangler should be left alone and the type printer updated, as far
as I'm concerned - preferably to the GCC3 demangler style.  It
currently "mostly" matches the v2 style.  See the thread
"RFC: Formatting of type output" and particularly my last message in it
for examples.  That was... December 6th 2001.

>    Also, gdb is including artificial arguments in the printed
>    representation of the constructors for vB-vD.  The dwarf2 output
>    indicates that they are artificial; gdb should not print them.  There
>    doesn't seem to be a simple way to handle this in the current gdb data
>    structures.

What artificial arguments?  Or do you mean with GCC 2.95, where these
tests are XFAILd because of this?

>   cplusfuncs.exp: cp-demangle bug.  The code to handle demangling
>    pointers-to-functions isn't complex enough.

OK.  Would you mind marking the overly simplistic result as an XFAIL
(or do you anticipate it being fixed soon?)

>   local.exp: The test tries to examine InnerLocal outside of its scope,
>    which fails.  Doing a ptype while InnerLocal is in scope works fine.
>    Meanwhile, ptype Local works outside of Local's scope; apparently being
>    inside an additional block makes a difference.  This definitely seems
>    like a gdb issue.

I'll investigate this one later.

>   method.exp: The 'print this' tests are failing because gdb is printing
>    the types as, say, (A * const), and the test just wants (A *).  The
>    former is correct, since 'this' is readonly.  Any objection to changing
>    the test (and others affected) to allow the const?

The standard, or at least Stroustrop seems to disagree - this came up yesterday
on gdb-patches.  He claims it should be A *, but not changeable.  I
don't care.

>   namespace.exp: gdb prints '\0', the testcase expects '\000'.  An obvious
>    fix, which I will apply.

Oh, so that's what it was!  Thanks.

>   templates.exp: the artificial args problem breaks destructor
>    recognition.  Also, when asked to set a breakpoint on a constructor, gdb
>    offers a menu of the different clones, which the testcase doesn't
>    like; it seems correct to me.

I have:
break T5<int>::T5
the class T5<int> does not have any method named T5
Hint: try 'T5<int>::T5<TAB> or 'T5<int>::T5<ESC-?>
(Note leading single quote.)
(gdb) FAIL: gdb.c++/templates.exp: constructor breakpoint

for stabs, also.

Then with DWARF-2 I get a few type printing errors, and the constructor
menu.  I'll look at how that is done and try to make it work for stabs
too.  So please recognize the menu in the testsuite.  What about the
destructor test that fails?  And Garply is probably a cv-placement bug.

>    Also, the cv-qual placement issue breaks 'print Foo<volatile char *>::foo';
>    it needs to be 'print "Foo<char volatile*>::foo"' to match the demangler
>    output.  I take it the aCC demangler makes different choices?  I don't
>    see any way to get around the dependence of template naming on the
>    canonical format chosen by the demangler unless gdb learns to mangle
>    names itself; perhaps the syntax of the test should vary with the compiler.

Yes, it should.

Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]