From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30143 invoked by alias); 26 Feb 2003 01:03:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30135 invoked from network); 26 Feb 2003 01:03:10 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 26 Feb 2003 01:03:10 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1Q12qS16806; Tue, 25 Feb 2003 17:02:52 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] gdb.c++/templates.exp, pr gdb/1063 References: <20030226001536.GB31684@nevyn.them.org> <20030226003426.GA32574@nevyn.them.org> From: David Carlton Date: Wed, 26 Feb 2003 01:03:00 -0000 In-Reply-To: <20030226003426.GA32574@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00683.txt.bz2 On Tue, 25 Feb 2003 19:34:26 -0500, Daniel Jacobowitz 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