From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7928 invoked by alias); 26 Feb 2003 01:35:55 -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 7921 invoked from network); 26 Feb 2003 01:35:55 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 26 Feb 2003 01:35:55 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1Q0UUq16666; Tue, 25 Feb 2003 16:30:30 -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> From: David Carlton Date: Wed, 26 Feb 2003 01:35:00 -0000 In-Reply-To: <20030226001536.GB31684@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/msg00688.txt.bz2 On Tue, 25 Feb 2003 19:15:36 -0500, Daniel Jacobowitz said: > Note that we can't print out the above in stabs or dwarf-2; neither of > them puts the abstract type in the debug info, only the referenced > type. DWARF-2 can say a bit more than it does now - specifically, that > "int" is a template paramater for C - but "DWARF does not represent the > generic template definition, but does represent each instantiation" > according to the v3 draft. Thanks for the info; I hadn't gotten around to looking at the relevant parts of the DWARF standard yet. > The reason we often print out one of the instantiations is because each > C contains a nested typedef for C in the DWARF-2. We don't handle > nested types right yet. Ah. Hmm. Why does it contain a nested typedef for C? I guess that makes sense: 14.6p2 gives an example of how you can use C to refer to C within the definition of C. 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? David Carlton carlton@math.stanford.edu