Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: gdb@sources.redhat.com
Cc: Jason Merrill <jason@redhat.com>
Subject: gdb.c++ failures
Date: Thu, 10 Jan 2002 05:18:00 -0000	[thread overview]
Message-ID: <wvlbsg2gxa3.fsf@prospero.cambridge.redhat.com> (raw)

I've been looking at the various C++ debugging failures on
i686-pc-linux-gnu using dwarf2.  Here's my analysis:

  anon-union.exp: The C++ compiler is emitting an extra lexical block, so
   the breakpoint on the closing brace is treated as being outside the
   scope of the variable.  There are two issues here: The compiler output
   is wrong, and the testcase is relying on corner-case behavior that only
   works for the outermost block of a function.  Of course, I don't know
   how we could test for the compiler bug without doing this, so I suppose
   we might as well leave the testcase alone.

  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?

   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.

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

  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.

  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?

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

  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.

   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.

Jason


             reply	other threads:[~2002-01-10 13:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-10  5:18 Jason Merrill [this message]
2002-01-10 11:52 ` Daniel Jacobowitz
2002-01-10 12:59   ` Jason Merrill
2002-01-10  9:12 Michael Elizabeth Chastain
2002-01-10 11:21 ` Jason Merrill
2002-01-10 11:32   ` Daniel Jacobowitz
2002-01-10 13:25     ` Jason Merrill
2002-01-11 17:11       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wvlbsg2gxa3.fsf@prospero.cambridge.redhat.com \
    --to=jason@redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox