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

[David Carlton <carlton at kealia dot com>]

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.)

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