Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@www.cgsoftware.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Michael Elizabeth Chastain <chastain@cygnus.com>,
	dberlin@redhat.com, fnasser@redhat.com,
	gdb-patches@sources.redhat.com
Subject: Re: [RFA] testsuite/gdb.c++/ref-types.exp: use runto
Date: Sat, 17 Mar 2001 07:56:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.10.10103161720250.7434-100000@www.cgsoftware.com> (raw)
In-Reply-To: <3AB283AC.FD95FEEE@cygnus.com>

On Fri, 16 Mar 2001, Fernando Nasser wrote:

> Michael Elizabeth Chastain wrote:
> > 
> > Mmmm, a philosophical dispute.
> > 
> > Daniel Berlin writes:
> > > They need to be xfail'd for old-abi, but not for new-abi.
> > 
> > I believe that when gdb has a bug which is under its control, that the
> > test suite should issue a FAIL, not an XFAIL.
> > 
> 
> Yes, but what Dan is trying to say (I guess) is that this is _not_
> under GDB's control. I.e., it was not possible for GDB to do the right
> thing because of insufficient information from the compiler.  Is that
> right Dan?
> 
Yes.
Insufficient information, too many possibilities, and
too much of a performance hit.
There are too many combinations, and no easy way to tell them apart.
You'd end up with like at least 96 cases (4 possible vtable-thunks
flags * 2 cases for each type of vtbl_ptr_type * 3 normal cases * the ABI
changed four times)
in just to determine which virtual function to call.
Then another 96 to determine how to offset the pointer, etc.

This doesn't even count the logic necessary to fill in the information we
don't have from the debug info (the offset of the virtual thunk, etc),
which would take a huge performance hit to try to figure out.
 > If that is
the case, it is correct to mark those as XFAILs.
>Something besides GDB -- something in the execution environment or on
>another piece of the toolchain -- causes this test to fail and there is
>not that can be done inside GDB, so the "expected failure".
> 
> Maybe you guys can come up with a simple quick test to determine if we
> are dealing with v2 or v3.  It would be useful to condition tests.

I added a simple if to the minsym demangling (where it goes through all
the minimal symbols and demangles them) to determine if we were dealing
with v3 or v2, and set the ABI approriately.

I can add a simple maintenance command to print out the C++ ABI shortname
(gnu-v3, gnu-v2, hpaCC), and you could use that, I think.
> > If gdb said "I'm sorry, but pAe->f() is too complex for me", I would
> > accept that as an XFAIL.  But when gdb prints wrong answers, that should
> > be a FAIL.
> > 
> > I'm interested in other maintainer's opinions on this because I'm
> > planning to submit patches to change such XFAIL's to FAIL's, so that
> > the test suite can actually report what is broken in C++ support.
Pleaes don't do this for v2.
It's not broken. It's something we can't fix.
I've already got them *all* working for v3 ABI.

--Dan



  parent reply	other threads:[~2001-03-17  7:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-16 13:15 Michael Elizabeth Chastain
2001-03-16 13:21 ` Fernando Nasser
2001-03-16 15:14   ` Peter.Schauer
2001-03-16 15:17     ` Daniel Berlin
2001-03-16 15:45       ` Michael Snyder
2001-03-16 15:49         ` Daniel Berlin
2001-03-16 15:19   ` Andrew Cagney
2001-03-16 15:21     ` Daniel Berlin
2001-03-17  7:56   ` Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-03-17 14:37 Michael Elizabeth Chastain
2001-03-17 12:42 Michael Elizabeth Chastain
2001-03-17 15:31 ` Daniel Berlin
2001-03-17 12:35 Michael Elizabeth Chastain
2001-03-17 14:23 ` Daniel Berlin
2001-03-16 21:00 Michael Elizabeth Chastain
2001-03-17 11:12 ` Daniel Berlin
2001-03-16 16:03 Michael Elizabeth Chastain
2001-03-16 14:50 Michael Elizabeth Chastain
2001-03-16 14:55 ` Daniel Berlin
2001-03-16 14:49 Michael Elizabeth Chastain
2001-03-16 14:55 ` Daniel Berlin
     [not found] ` <20010316215907.A3607@redhat.com>
2001-03-17 11:59   ` Daniel Berlin
2001-03-16 14:35 Michael Elizabeth Chastain
2001-03-16 14:40 ` Fernando Nasser
2001-03-16 14:43 ` Daniel Berlin
2001-03-16 14:44 ` Daniel Berlin
     [not found] <200103161807.KAA06081@bosch.cygnus.com>
2001-03-16 12:00 ` Fernando Nasser
2001-03-16 13:00 ` Daniel Berlin
2001-03-16 14:29   ` Michael Snyder
2001-03-04 15:25 Michael Elizabeth Chastain
2001-02-24  0:16 Michael Elizabeth Chastain

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=Pine.LNX.4.10.10103161720250.7434-100000@www.cgsoftware.com \
    --to=dan@www.cgsoftware.com \
    --cc=chastain@cygnus.com \
    --cc=dberlin@redhat.com \
    --cc=fnasser@cygnus.com \
    --cc=fnasser@redhat.com \
    --cc=gdb-patches@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