From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19525 invoked by alias); 2 Jul 2003 16:38:11 -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 19511 invoked from network); 2 Jul 2003 16:38:11 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 2 Jul 2003 16:38:11 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19XkdP-00023G-00; Wed, 02 Jul 2003 11:39:07 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19XkcQ-00004y-00; Wed, 02 Jul 2003 12:38:06 -0400 Date: Wed, 02 Jul 2003 16:38:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [patch/testsuite] gdb.c++/classes.exp: add another ptype pattern Message-ID: <20030702163806.GA32728@nevyn.them.org> Mail-Followup-To: David Carlton , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <200307021609.h62G9XaE025486@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00036.txt.bz2 On Wed, Jul 02, 2003 at 09:29:17AM -0700, David Carlton wrote: > 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.) We should either fix GCC to emit namespace markers for stabs, as Sun defines them, or to always emit fully qualified names. Nothing else is worth handling. Someone wise pointed out that ClassWithEnum::ClassWithEnum::PrivEnum and ClassWithEnum::PrivEnum are the same thing in C++, by the way. So we can handle that problem fine. > 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. Yes, precisely. At that point we should also print out "enum PrivEnum;" in the class type! Well, I think. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer