Re: [patch/testsuite] gdb.c++/classes.exp: add another ptype pattern

[Daniel Jacobowitz <drow at mvista dot com>]

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 <mec@shout.net> 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