From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15914 invoked by alias); 2 Jul 2003 16:29:19 -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 15895 invoked from network); 2 Jul 2003 16:29:18 -0000 Received: from unknown (HELO hawaii.kealia.com) (216.101.126.244) by sources.redhat.com with SMTP; 2 Jul 2003 16:29:18 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id CB6F6BFE3; Wed, 2 Jul 2003 09:29:17 -0700 (PDT) To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/testsuite] gdb.c++/classes.exp: add another ptype pattern References: <200307021609.h62G9XaE025486@duracef.shout.net> From: David Carlton Date: Wed, 02 Jul 2003 16:29:00 -0000 In-Reply-To: <200307021609.h62G9XaE025486@duracef.shout.net> (Michael Elizabeth Chastain's message of "Wed, 2 Jul 2003 12:09:33 -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-07/txt/msg00035.txt.bz2 On Wed, 2 Jul 2003 12:09:33 -0400, Michael Elizabeth Chastain said: dc> # NOTE: carlton/2003-07-02: Currently, this test only passes with GCC dc> # 3.3 and higher and with -gstabs+, and it only passes in those dc> # situations by accident. > Ummm, could you explain the accident more? > There's already KFAIL on the naked 'PrivEnum' because gdb prints it for > a "bad reason". But if gdb prints 'ClassWithEnum::PrivEnum' then you > say it's by accident. It's like there is nothing gdb to can do to avoid > scolding by the test script. > This is getting too far away from my vision of a test suite, which is > that it defines the legal output for a PASS, and then KFAIL's and > XFAIL's other cases that we understand, and then FAIL's everything else. > In the long run, should 'class ClassWithEnum { PrivEnum ...}' be a PASS? > In the long run, should 'class ClassWithEnum { ClassWithEnum::PrivEnum ...}' > be a PASS? Here's the picture, as I see it: Right now, GDB doesn't understand nested types (by which I mean types that are contained in classes or in namespaces). GDB's typical way of dealing with them is to forget that they actually live in an enclosing type, but instead to put their names at the top level. (Which is why we typically see "PrivEnum" instead of "ClassWithEnum::PrivEnum".) I'm in the process of merging some code into mainline that will dramatically improve this situation for DWARF-2. At that point, GDB will start printing ClassWithEnum::PrivEnum a lot more frequently, turning a lot of KFAILs into PASSes. This is a good thing. That will only affect DWARF-2, however, not stabs. What I'm worried about is this: maybe at some point somebody will try to do a similar task for stabs. It won't work as well (because stabs doesn't like nesting constructs), but there are tricks that you can play. If we're in that situation, we'll be depending very much on GCC's output. And I could imagine that GCC calling that type ClassWithEnum::PrivEnum instead of just PrivEnum would screw us up, maybe causing GDB to do something like call the type ClassWithEnum::ClassWithEnum::PrivEnum, with no way for GDB to get the correct output with both GCC 3.2 and with GCC 3.3. (That's just hypothetical, and actually is fairly unlikely in this case, since it's an enum, but I could imagine similar situation where something like that might happen.) So what I want in the test case is a note saying that, if you see a regression in this particular circumstance, then it's not necessarily a bad thing: GDB might have improved in a way that happens to interact badly with the output of one specific version of GCC. (And, once I fix GDB to generate more honest passes for DWARF-2, I'll modify the test suite comment accordingly.) As to this question: > In the long run, should 'class ClassWithEnum { PrivEnum ...}' be a PASS? I think that Daniel has a vision where this eventually becomes a PASS. But that's a longer-term goal: if it become a PASS, it will do so for a two-stage reason, where GDB knows that the type in question is _really_ ClassWithEnum::PrivEnum but where the printer is clever enough to know that, while we're printing out ClassWithEnum, we can omit ClassWithEnum:: prefixes. David Carlton carlton@kealia.com