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: Re: gdb.c++ failures
Date: Thu, 10 Jan 2002 12:59:00 -0000	[thread overview]
Message-ID: <wvlpu4hexcf.fsf@prospero.cambridge.redhat.com> (raw)
In-Reply-To: <20020110145303.C9479@nevyn.them.org> (Daniel Jacobowitz's message of "Thu, 10 Jan 2002 14:53:03 -0500")

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> On Thu, Jan 10, 2002 at 01:17:56PM +0000, Jason Merrill wrote:

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

Works for me.

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

With dwarf2, the in-class abstract declaration of the constructor has
artificial parms for "in charge" and the VTT pointer.  The "in charge"
parameter is specialized away in both clones, and the VTT is is specialized
away in one of them, but both should be represented in the debug info,
ideally with DW_AT_const_value attributes where they have been specialized.

>> 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?)

Will do.

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

Stroustrup is right; for whatever reason, the language specifies that
'this' is not an lvalue, so not only is it immutable, but you can't take
its address either.  I think it's more useful for the debugging information
to point at the hidden parameter used to pass the value of 'this' into the
function, for which A*const is a perfectly sensible type.

Jason


  reply	other threads:[~2002-01-10 20:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-10  5:18 Jason Merrill
2002-01-10 11:52 ` Daniel Jacobowitz
2002-01-10 12:59   ` Jason Merrill [this message]
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=wvlpu4hexcf.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