From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30299 invoked by alias); 27 May 2002 18:27:58 -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 30289 invoked from network); 27 May 2002 18:27:55 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 27 May 2002 18:27:55 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g4RIRrb24032; Mon, 27 May 2002 13:27:53 -0500 Date: Mon, 27 May 2002 11:38:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200205271827.g4RIRrb24032@duracef.shout.net> To: drow@mvista.com Subject: Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types Cc: gdb-patches@sources.redhat.com X-SW-Source: 2002-05/txt/msg00945.txt.bz2 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. 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. 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? Michael C