Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] gdb.c++/templates.exp, pr gdb/1063
Date: Wed, 26 Feb 2003 01:03:00 -0000	[thread overview]
Message-ID: <ro1isv7ua4j.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <20030226003426.GA32574@nevyn.them.org>

On Tue, 25 Feb 2003 19:34:26 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Tue, Feb 25, 2003 at 04:30:29PM -0800, David Carlton wrote:

>> In that case, I don't think that the desire of the original test case
>> (i.e. printing out actual template info) is reasonable: it's not the
>> job of GDB's test suite to lobby for improvements in debugging
>> formats.  So I think the proper behavior is to delete the original
>> success regexps, to decide that, in this situation, GDB shouldn't
>> print out any information (which is what currently happens with GCC
>> 2.95.3/stabs), to KFAIL the situations where it does print out an
>> instantiation with reference to a PR about nested classes (I assume we
>> have such a PR, if not I'll create one), and to close PR 1063 with an
>> appropriate comment.
>> 
>> How does that sound?

> Or run the test only for HP, which _does_ have this information.

> Does any of the code still work?  I've got no idea.  I only ran the C
> testsuites on HP/UX, not the C++ ones.

I confess, I'm not too thrilled about the idea of maintaining
HP-specific tests or regexps in the test suite.  There's way too much
HP-specific code in GDB already, and it's a pain to have to figure out
whether or not that code is doing something that can't be done in the
non-HP situation, that should be done in the non-HP situation, that
could (possibly is) be done identically in the HP- and non-HP
situation but is gratuitously incompatible for no good reason, or
whatever.  It's hard enough work getting GDB to work decently with GCC
2.95.3 and GCC 3.1 or newer with stabs+ and DWARF-2, which is what we
officially support; I really don't want to spend any effort on
anything else.

Having said that, one could certainly argue that leaving those regexps
in place doesn't count as "spending any effort"!  But I'd rather leave
those tests in place, and run them on all platforms, instead of
running the test only for HP.  In which case we should either PASS or
XFAIL the non-HP regexps; I'd vote for PASS.  (Though of course we
should KFAIL the case where GDB gets it wrong because of nested
types.)

Hmm.  I guess, for now, just leaving the HP regexps in place is
correct.  At some point, we should consider making a policy decision
on this: in an ideal world, we would go through the current PASS
regexps in all the tests just to make sure that we really think those
PASS regexps are proper behavior that might be observed by GDB.  And,
at that point, the HP regexps will actively get in our way.  But until
then, I suppose it doesn't hurt to leave them there.

So my current plan is to leave the HP regexps (but add a comment), to
PASS the case where GDB can't print out the type info, to KFAIL the
case where GDB incorrectly prints out one of the specializations (with
reference to a nested types PR), and to close PR gdb/1063 (with an
appropriate comment).  How does that sound?

David Carlton
carlton@math.stanford.edu


  reply	other threads:[~2003-02-26  1:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-26  0:35 David Carlton
2003-02-26  0:15 ` Daniel Jacobowitz
2003-02-26  1:35   ` David Carlton
2003-02-26  0:34     ` Daniel Jacobowitz
2003-02-26  1:03       ` David Carlton [this message]
2003-02-26 20:27         ` David Carlton
2003-02-26  1:15 Michael Elizabeth Chastain
2003-02-26  1:23 ` David Carlton
2003-02-26  2:00 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=ro1isv7ua4j.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=drow@mvista.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