From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32655 invoked by alias); 27 May 2002 18:38:15 -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 32648 invoked from network); 27 May 2002 18:38:14 -0000 Received: from unknown (HELO branoic) (12.234.96.134) by sources.redhat.com with SMTP; 27 May 2002 18:38:14 -0000 Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17CPNf-0007fi-00; Mon, 27 May 2002 14:38:07 -0400 Date: Mon, 27 May 2002 11:41:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types Message-ID: <20020527183807.GA23823@branoic.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <200205271827.g4RIRrb24032@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205271827.g4RIRrb24032@duracef.shout.net> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-05/txt/msg00946.txt.bz2 On Mon, May 27, 2002 at 01:27:53PM -0500, Michael Elizabeth Chastain wrote: > Daniel Jacobowitz writes: > > mec> This patch updates local.exp to track an improvement in gdb. > mec> In a configuration with gcc HEAD -gstabs+, gdb prints nested types > mec> as "InnerLocal::NestedInnerLocal" instead of just "NestedInnerLocal". > > dj> It's an improvement in GCC's debug output, I believe; I seem to recall > dj> Kevin posting a patch for this to gcc-patches recently. > > I don't think it's a change in gcc because gcc does not show this change > with gdb 5.2 or gdb gdb_5_2-branch. It happens only with gdb HEAD. > > Although there have been changes in gcc this week in this area. Perhaps > it really is a gcc change, and gdb HEAD is the only gdb looking at the > area of the change. Let's go with a working philosophy of "both" then :) > dj> Is it really? It seems to me that we should strip off the name of the > dj> enclosing class from nested types. This becomes more of an issue with > dj> the DWARF-2 type printing I'm experimenting with. > > This is a philosophical issue. Let's explore it. Indeed it is. > gdb's output is: > > # target=native, host=i686-pc-linux-gnu%rh-7.2, gdb=HEAD%20020526 > # gcc=HEAD%20020526, binutils=HEAD%20020526, glibc=VENDOR, > # goption=-gstabs+ > > ptype InnerLocal > type = class InnerLocal { > public: > char ilc; > int *ip; > InnerLocal::NestedInnerLocal nest1; > > InnerLocal & operator=(InnerLocal const&); > InnerLocal(InnerLocal const&); > InnerLocal(); > int il_foo(unsigned char const&); > } > > gdb presents me with this output. What result should I assign to it? > > I think this is a PASS. I think that the output is clear to humans. > The construct "InnerLocal::NestedInnerLocal nest1" is also valid C++; > if you add back in the definition of NestedInnerLocal, then it will > compile. > > I also accept "NestedInnerLocal nest1;" as a PASS. > > Philosophically, I'm not interested in the "one true output". I look > at what gdb actually prints in each configuration, and then classify > these into PASS and FAIL. This is especially true for "ptype" output, > where the output depends on the compiler and debug format. > > What do you think? I think that I (as C++ maintainer rather than testsuite maintainer) need to figure out what the correct output is. "InnerLocal::NestedInnerLocal nest1" is not actually valid C++ in general, I don't believe; what if there is a class InnerLocal::InnerLocal::NestedInnerLocal? I believe it will resolve to that one instead of the correct one. This is also uglier; for std:: types there's going to be a lot of useless noise. The ideal output, it seems to me, would be something like: > ptype InnerLocal > type = class InnerLocal { > public: > char ilc; > int *ip; > class NestedInnerLocal; > NestedInnerLocal nest1; > > InnerLocal & operator=(InnerLocal const&); > InnerLocal(InnerLocal const&); > InnerLocal(); > int il_foo(unsigned char const&); > } Unambiguous, quite obviously correct. By this logic, InnerLocal::NestedInnerLocal deserves a KFAIL comment for the moment, since the code to do this is not yet present. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer