From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13543 invoked by alias); 29 Sep 2003 20:19:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13532 invoked from network); 29 Sep 2003 20:19:06 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 29 Sep 2003 20:19:06 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 9CD30CB30; Mon, 29 Sep 2003 11:10:15 -0700 (PDT) To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com Subject: Re: sunday project, gdb, 2003-09-26 References: <200309272108.h8RL8LLA009276@duracef.shout.net> From: David Carlton Date: Mon, 29 Sep 2003 22:00:00 -0000 In-Reply-To: <200309272108.h8RL8LLA009276@duracef.shout.net> (Michael Elizabeth Chastain's message of "Sat, 27 Sep 2003 17:08:21 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00384.txt.bz2 On Sat, 27 Sep 2003 17:08:21 -0400, Michael Elizabeth Chastain said: > . gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 > PASS -> KFAIL > This is a regression in gdb. The KFAIL is: > http://sources.redhat.com/gdb/bugs/826 > variables in C++ namespaces have to be enclosed in quotes > This happened with gcc v3 -gstabs+. GCC 3.3, specifically: I don't see this with 3.2, where it's always been a KFAIL. The debug info for stabs changed from 3.2 to 3.3, I seem to recall. > # gdb.log > # gdb 2003-09-26 10:32:21 UTC > # gcc 3.3.1, binutils 2.14, -gstabs+ > print (ClassWithEnum::PrivEnum) 42 > A syntax error in expression, near `42'. > (gdb) KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826) > print ('ClassWithEnum::PrivEnum') 42 > $26 = yellow > (gdb) PASS: gdb.cp/classes.exp: print ('ClassWithEnum::PrivEnum') 42 Yes. Unfortunately, this is a problem with the parser: the lexer used to (badly) handle nested types, and now the parser (badly) handles nested types, and this is an area where the parser does a worse job than the lexer used to. Sigh. > . gdb.cp/local.exp: ptype InnerLocal::NestedInnerLocal > FAIL -> KFAIL > @ 113 115 117 119 121 123 125 127 129 131 133 135 > This is a regression in gdb. The KFAIL is: > http://sources.redhat.com/gdb/bugs/482 > gdb.c++/local.exp: ptype InnerLocal::NestedInnerLocal > This happened with gcc v3 -gstabs+. > gdb.log excerpts: > # gdb.log > # gdb 2003-09-23 00:57:26 UTC > # gcc 3.3.1, binutils 2.14, -gstabs+ > ptype InnerLocal::NestedInnerLocal > type = class InnerLocal::NestedInnerLocal { > public: > int nil; > InnerLocal::NestedInnerLocal & operator=(InnerLocal::NestedInnerLocal const& > ); > NestedInnerLocal(InnerLocal::NestedInnerLocal const&); > NestedInnerLocal(); > int nil_foo(int); > } > (gdb) FAIL: gdb.cp/local.exp: ptype InnerLocal::NestedInnerLocal > # gdb.log > # gdb 2003-09-26 10:32:21 UTC > # gcc 3.3.1, binutils 2.14, -gstabs+ > ptype InnerLocal::NestedInnerLocal > There is no field named NestedInnerLocal > (gdb) KFAIL: gdb.cp/local.exp: ptype InnerLocal::NestedInnerLocal (PRMS: gdb/482) Right: at first, I was wondering why you called this a regression, given that it started out as a FAIL, but it really is the case that the new output is worse. (Is there anything wrong with the old output? It looks completely correct to me.) Again, this is specific to GCC 3.3, stabs; unlike the previous problem, however, this one will get fixed once I get nested types working more fully. David Carlton carlton@kealia.com