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

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

[Michael Elizabeth Chastain]

dc> Sigh.  Do the GCC stabs maintainers just randomly change their output
dc> to keep us on our toes, or what?

Something like that.  :)

Ha!  And they LAUGHED when I kept both 3.2.3 and 3.3 in my test bed!  :)

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?

That would help me sort this out.

Michael C

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

[David Carlton]

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

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

[Daniel Jacobowitz]

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

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

[Michael Elizabeth Chastain]

Okay, here's my understanding:

. as of gcc 3.3, enums and classes which are nested in other classes now
  have a stab name such as "ClassWithEnum::PrivEnum" rather than just
  "PrivEnum".

. this is intentional

. this is a good thing -- drow mentioned it at one point and carlton
  likes it too.

. as of gcc 3.3, enums and classes which are nested in namespaces
  still have stab names such as "PrivEnum".

. there's still work to do in gdb.

. ... so it's hard to write a test case.

I'm going to leave inherit.exp alone and withdraw my patch.  This will
leave the gcc 3.3 -gstabs+ case with a FAIL, which is okay.  Someone will
pick it up again later when they get to the work in gdb.

I'm satisfied that the change from gcc 3.2.3 to gcc 3.3 is a good change.
So I can proceed down my list of "regressions with gcc 3.3 versus
gcc 3.2.3".  When I get to the bottom of that list, I can drop test
coverage of gcc 3.2.3.

Michael C

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

[Michael Elizabeth Chastain]

dc> Does this give fully-qualified names for types defined in namespaces,
dc> too?

Doh, I misread david's question.

kb> I guess the answer is, "Try it and let me know..."

Kevin's recollection matches what I see here ... types defined in namespaces
still have unqualifed names with gcc 3.3.  Same with gcc HEAD.

Michael C

=== namespace.cc

namespace Foo
{
  class NestedClass { public: int alpha; };
  enum NestedEnum { red, green, blue, yellow = 42 };
  typedef double NestedTypedef;

  NestedClass nc_1;
  NestedEnum ne_1;
  NestedTypedef nt_1;
};

Foo::NestedClass nc_2;
Foo::NestedEnum ne_2;
Foo::NestedTypedef nt_2;

=== namespace.323.s

	.file	"namespace.cc"
	.stabs	"/berman/home/mgnu/tmp/cwe/",100,0,0,.Ltext0
	.stabs	"namespace.cc",100,0,0,.Ltext0
	.text
.Ltext0:
	.stabs	"gcc2_compiled.",60,0,0,0
	.stabs	"int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
	.stabs	"char:t(0,2)=r(0,2);0;127;",128,0,0,0
	.stabs	"long int:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0
	.stabs	"unsigned int:t(0,4)=r(0,4);0000000000000;0037777777777;",128,0,0,0
	.stabs	"long unsigned int:t(0,5)=r(0,5);0000000000000;0037777777777;",128,0,0,0
	.stabs	"long long int:t(0,6)=@s64;r(0,6);01000000000000000000000;0777777777777777777777;",128,0,0,0
	.stabs	"long long unsigned int:t(0,7)=@s64;r(0,7);0000000000000;01777777777777777777777;",128,0,0,0
	.stabs	"short int:t(0,8)=@s16;r(0,8);-32768;32767;",128,0,0,0
	.stabs	"short unsigned int:t(0,9)=@s16;r(0,9);0;65535;",128,0,0,0
	.stabs	"signed char:t(0,10)=@s8;r(0,10);-128;127;",128,0,0,0
	.stabs	"unsigned char:t(0,11)=@s8;r(0,11);0;255;",128,0,0,0
	.stabs	"float:t(0,12)=r(0,1);4;0;",128,0,0,0
	.stabs	"double:t(0,13)=r(0,1);8;0;",128,0,0,0
	.stabs	"long double:t(0,14)=r(0,1);12;0;",128,0,0,0
	.stabs	"complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
	.stabs	"complex float:t(0,16)=R3;8;0;",128,0,0,0
	.stabs	"complex double:t(0,17)=R4;16;0;",128,0,0,0
	.stabs	"complex long double:t(0,18)=R5;24;0;",128,0,0,0
	.stabs	"wchar_t:t(0,19)=r(0,19);-2147483648;2147483647;",128,0,0,0
	.stabs	"__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
	.stabs	"bool:t(0,21)=@s8;-16;",128,0,0,0
	.stabs	"__vtbl_ptr_type:t(0,22)=*(0,23)=f(0,1)",128,0,0,0
	.stabs	"namespace.cc",130,0,0,0
	.stabs	"NestedClass:Tt(1,1)=s4alpha:(0,1),0,32;operator=::(1,2)=#(1,1),(1,3)=&(1,1),(1,4)=*(1,1),(1,5)=&(1,6)=k(1,1),(1,7)=(1,7);:_ZN3Foo11NestedClassaSERKS0_;2A.;__base_ctor::(1,8)=#(1,1),(1,7),(1,4),(1,5),(1,7);:_ZN3Foo11NestedClassC2ERKS0_;2A.;__comp_ctor::(1,8):_ZN3Foo11NestedClassC1ERKS0_;2A.;__base_ctor::(1,9)=#(1,1),(1,7),(1,4),(1,7);:_ZN3Foo11NestedClassC2Ev;2A.;__comp_ctor::(1,9):_ZN3Foo11NestedClassC1Ev;2A.;;",128,0,3,0
	.stabs	"NestedEnum:t(1,10)=ered:0,green:1,blue:2,yellow:42,;",128,0,4,0
	.stabs	"NestedTypedef:t(1,11)=(0,13)",128,0,5,0
.globl _ZN3Foo4nc_1E
	.bss
	.align 4
	.type	_ZN3Foo4nc_1E,@object
	.size	_ZN3Foo4nc_1E,4
_ZN3Foo4nc_1E:
	.zero	4
.globl _ZN3Foo4ne_1E
	.align 4
	.type	_ZN3Foo4ne_1E,@object
	.size	_ZN3Foo4ne_1E,4
_ZN3Foo4ne_1E:
	.zero	4
.globl _ZN3Foo4nt_1E
	.align 8
	.type	_ZN3Foo4nt_1E,@object
	.size	_ZN3Foo4nt_1E,8
_ZN3Foo4nt_1E:
	.zero	8
.globl nc_2
	.align 4
	.type	nc_2,@object
	.size	nc_2,4
nc_2:
	.zero	4
.globl ne_2
	.align 4
	.type	ne_2,@object
	.size	ne_2,4
ne_2:
	.zero	4
.globl nt_2
	.align 8
	.type	nt_2,@object
	.size	nt_2,8
nt_2:
	.zero	8
	.stabs	"nc_1:G(1,1)",32,0,7,0
	.stabs	"ne_1:G(1,10)",32,0,8,0
	.stabs	"nt_1:G(1,11)",32,0,9,0
	.stabs	"nc_2:G(1,1)",32,0,12,0
	.stabs	"ne_2:G(1,10)",32,0,13,0
	.stabs	"nt_2:G(1,11)",32,0,14,0
	.text
	.stabs "",100,0,0,.Letext
.Letext:
	.ident	"GCC: (GNU) 3.2.3"

=== namespace.33.s

	.file	"namespace.cc"
	.stabs	"/berman/home/mgnu/tmp/cwe/",100,0,0,.Ltext0
	.stabs	"namespace.cc",100,0,0,.Ltext0
	.text
.Ltext0:
	.stabs	"gcc2_compiled.",60,0,0,0
	.stabs	"int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
	.stabs	"char:t(0,2)=r(0,2);0;127;",128,0,0,0
	.stabs	"long int:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0
	.stabs	"unsigned int:t(0,4)=r(0,4);0000000000000;0037777777777;",128,0,0,0
	.stabs	"long unsigned int:t(0,5)=r(0,5);0000000000000;0037777777777;",128,0,0,0
	.stabs	"long long int:t(0,6)=@s64;r(0,6);01000000000000000000000;0777777777777777777777;",128,0,0,0
	.stabs	"long long unsigned int:t(0,7)=@s64;r(0,7);0000000000000;01777777777777777777777;",128,0,0,0
	.stabs	"short int:t(0,8)=@s16;r(0,8);-32768;32767;",128,0,0,0
	.stabs	"short unsigned int:t(0,9)=@s16;r(0,9);0;65535;",128,0,0,0
	.stabs	"signed char:t(0,10)=@s8;r(0,10);-128;127;",128,0,0,0
	.stabs	"unsigned char:t(0,11)=@s8;r(0,11);0;255;",128,0,0,0
	.stabs	"float:t(0,12)=r(0,1);4;0;",128,0,0,0
	.stabs	"double:t(0,13)=r(0,1);8;0;",128,0,0,0
	.stabs	"long double:t(0,14)=r(0,1);12;0;",128,0,0,0
	.stabs	"complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
	.stabs	"complex float:t(0,16)=R3;8;0;",128,0,0,0
	.stabs	"complex double:t(0,17)=R4;16;0;",128,0,0,0
	.stabs	"complex long double:t(0,18)=R5;24;0;",128,0,0,0
	.stabs	"wchar_t:t(0,19)=r(0,19);-2147483648;2147483647;",128,0,0,0
	.stabs	"__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
	.stabs	"bool:t(0,21)=@s8;-16;",128,0,0,0
	.stabs	"__vtbl_ptr_type:t(0,22)=*(0,23)=f(0,1)",128,0,0,0
	.stabs	"namespace.cc",130,0,0,0
	.stabs	"NestedClass:Tt(1,1)=s4alpha:(0,1),0,32;operator=::(1,2)=#(1,1),(1,3)=&(1,1),(1,4)=*(1,1),(1,5)=&(1,6)=k(1,1),(1,7)=(1,7);:_ZN3Foo11NestedClassaSERKS0_;2A.;__base_ctor::(1,8)=#(1,1),(1,7),(1,4),(1,5),(1,7);:_ZN3Foo11NestedClassC2ERKS0_;2A.;__comp_ctor::(1,8):_ZN3Foo11NestedClassC1ERKS0_;2A.;__base_ctor::(1,9)=#(1,1),(1,7),(1,4),(1,7);:_ZN3Foo11NestedClassC2Ev;2A.;__comp_ctor::(1,9):_ZN3Foo11NestedClassC1Ev;2A.;;",128,0,3,0
	.stabs	"NestedEnum:t(1,10)=ered:0,green:1,blue:2,yellow:42,;",128,0,4,0
	.stabs	"NestedTypedef:t(1,11)=(0,13)",128,0,5,0
.globl _ZN3Foo4nc_1E
	.bss
	.align 4
	.type	_ZN3Foo4nc_1E, @object
	.size	_ZN3Foo4nc_1E, 4
_ZN3Foo4nc_1E:
	.zero	4
.globl _ZN3Foo4ne_1E
	.align 4
	.type	_ZN3Foo4ne_1E, @object
	.size	_ZN3Foo4ne_1E, 4
_ZN3Foo4ne_1E:
	.zero	4
.globl _ZN3Foo4nt_1E
	.align 8
	.type	_ZN3Foo4nt_1E, @object
	.size	_ZN3Foo4nt_1E, 8
_ZN3Foo4nt_1E:
	.zero	8
.globl nc_2
	.align 4
	.type	nc_2, @object
	.size	nc_2, 4
nc_2:
	.zero	4
.globl ne_2
	.align 4
	.type	ne_2, @object
	.size	ne_2, 4
ne_2:
	.zero	4
.globl nt_2
	.align 8
	.type	nt_2, @object
	.size	nt_2, 8
nt_2:
	.zero	8
	.stabs	"nc_2:G(1,1)",32,0,12,0
	.stabs	"ne_2:G(1,10)",32,0,13,0
	.stabs	"nt_2:G(1,11)",32,0,14,0
	.stabs	"nc_1:G(1,1)",32,0,7,0
	.stabs	"ne_1:G(1,10)",32,0,8,0
	.stabs	"nt_1:G(1,11)",32,0,9,0
	.text
	.stabs "",100,0,0,.Letext
.Letext:
	.ident	"GCC: (GNU) 3.3"

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

[Michael Elizabeth Chastain]

Ah, and here is the rationale:

  http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01715.html

From my superficial knowledge, this appears to be actually just what we
want.  Is that right?

Michael C

===

2002-05-22  Kevin Buettner  <kevinb@redhat.com>

        * dbxout.c (dbxout_class_name_qualifiers): New function.
        (dbxout_symbol): Output class/struct qualifiers for a .stabs entry.

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

[Michael Elizabeth Chastain]

dc> It might be a good idea as part of a larger change (to the names of
dc> all nested classes).  It's probably not a great idea if the change
dc> only involves enums nested with classes, though others might disagree
dc> with me on that.

Ah, I threw a nested class into my little test program.  Its name in the
stabs changed from 'PrivClass' (3.2.3) to 'Outer::PrivClass' (3.3).  So
it's not just enums, it's nice and regular.

dc> What certainly isn't a good idea is that it's changed and nobody has
dc> bothered to discuss this with us.  Maybe a good course of action would
dc> be to post to gcc@ asking about it.

No end to this rabbit hole ...

I am inclined to proceed on the assumption that all gcc 3.X will
be like gcc 3.3 (gcc HEAD certainly is).  Let gcc 3.2 and previous
versions suffer.  Let gcc 2.95.3 suffer, too, although that hurts a bit
more.

I'm neutral on the question of starting a thread in gcc@.

Daniel J, what would you like to do?

Michael C

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

[Michael Elizabeth Chastain]

Ah, yeah, the problem with my questions is that they are at the end
of a pipeline with several stages.

Let's back up and look at what gcc outputs.  I made a small source file:

  class ClassWithEnum
  {
    public:
      enum PrivEnum { red, green, blue, yellow = 42 };
      PrivEnum priv_enum;
      int x;
  };

Then I hit it with gcc 3.2.3, and gcc 3.3 and diff'ed the .s files.

  -       .stabs  "PrivEnum:t(1,1)=ered:0,green:1,blue:2,yellow:42,;",128,0,4,0
  +       .stabs  "ClassWithEnum::PrivEnum:t(1,1)=ered:0,green:1,blue:2,yellow:42,;",128,0,4,0
	  .stabs  "ClassWithEnum:Tt(1,2)=s8priv_enum:(1,1),0,32;x:(0,1),32,32;operator=::(1,3)=#(1,2),(1,4)=&(1,2),(1,5)=*(1,2),(1,6)=&(1,7)=k(1,2),(1,8)=(1,8);:_ZN13ClassWithEnumaSERKS_;2A.;__base_ctor::(1,9)=#(1,2),(1,8),(1,5),(1,6),(1,8);:_ZN13ClassWithEnumC2ERKS_;2A.;__comp_ctor::(1,9):_ZN13ClassWithEnumC1ERKS_;2A.;__base_ctor::(1,10)=#(1,2),(1,8),(1,5),(1,8);:_ZN13ClassWithEnumC2Ev;2A.;__comp_ctor::(1,10):_ZN13ClassWithEnumC1Ev;2A.;;",128,0,2,0

The big stab for ClassWithEnum is the same, but the stab for the nested
enum changed from 'PrivEnum' to 'ClassWithEnum::PrivEnum'.  The
hypothetical case has came to life.  Argh!

Is it good for us that gcc 3.3 and later versions output
'ClassWithEnum::PrivEnum'?  Or should I file a bug report against gcc
and ask them to put it back to just plain 'PrivEnum'?

dc> I think that Daniel has a vision where this eventually becomes a
dc> PASS.  But that's a longer-term goal: if it become a PASS, it will do
dc> so for a two-stage reason, where GDB knows that the type in question
dc> is _really_ ClassWithEnum::PrivEnum but where the printer is clever
dc> enough to know that, while we're printing out ClassWithEnum, we can
dc> omit ClassWithEnum:: prefixes.

Ah, I see.

So it's hard to write the test case at this point.  But it's done the
job of alerting us to a difference in gcc output.

Michael C

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

[David Carlton]

On Wed, 2 Jul 2003 12:49:20 -0400, Michael Elizabeth Chastain <mec@shout.net> said:

> The big stab for ClassWithEnum is the same, but the stab for the
> nested enum changed from 'PrivEnum' to 'ClassWithEnum::PrivEnum'.
> The hypothetical case has came to life.  Argh!

> Is it good for us that gcc 3.3 and later versions output
> 'ClassWithEnum::PrivEnum'?  Or should I file a bug report against
> gcc and ask them to put it back to just plain 'PrivEnum'?

It might be a good idea as part of a larger change (to the names of
all nested classes).  It's probably not a great idea if the change
only involves enums nested with classes, though others might disagree
with me on that.

What certainly isn't a good idea is that it's changed and nobody has
bothered to discuss this with us.  Maybe a good course of action would
be to post to gcc@ asking about it.

> So it's hard to write the test case at this point.  But it's done the
> job of alerting us to a difference in gcc output.

Right.

David Carlton
carlton@kealia.com

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

[Daniel Jacobowitz]

On Wed, Jul 02, 2003 at 10:07:53AM -0700, David Carlton wrote:
> On Wed, 2 Jul 2003 12:49:20 -0400, Michael Elizabeth Chastain <mec@shout.net> said:
> 
> > The big stab for ClassWithEnum is the same, but the stab for the
> > nested enum changed from 'PrivEnum' to 'ClassWithEnum::PrivEnum'.
> > The hypothetical case has came to life.  Argh!
> 
> > Is it good for us that gcc 3.3 and later versions output
> > 'ClassWithEnum::PrivEnum'?  Or should I file a bug report against
> > gcc and ask them to put it back to just plain 'PrivEnum'?
> 
> It might be a good idea as part of a larger change (to the names of
> all nested classes).  It's probably not a great idea if the change
> only involves enums nested with classes, though others might disagree
> with me on that.
> 
> What certainly isn't a good idea is that it's changed and nobody has
> bothered to discuss this with us.  Maybe a good course of action would
> be to post to gcc@ asking about it.

Eh, I believe Kevin B. did it:

2002-05-22  Kevin Buettner  <kevinb@redhat.com>

        * dbxout.c (dbxout_class_name_qualifiers): New function.
        (dbxout_symbol): Output class/struct qualifiers for a .stabs entry.

Ask him about it instead of blaming GCC...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

On Jul 2,  2:32pm, Daniel Jacobowitz wrote:

> Eh, I believe Kevin B. did it:
> 
> 2002-05-22  Kevin Buettner  <kevinb@redhat.com>
> 
>         * dbxout.c (dbxout_class_name_qualifiers): New function.
>         (dbxout_symbol): Output class/struct qualifiers for a .stabs entry.
> 
> Ask him about it instead of blaming GCC...

See

    http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01715.html

(where I explain the motivation behind this change).

Yes, I should've cc'd this list.

Kevin

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

[David Carlton]

On Wed, 2 Jul 2003 12:02:33 -0700, Kevin Buettner <kevinb@redhat.com> said:

> See

>     http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01715.html

> (where I explain the motivation behind this change).

Ah, thanks.  That seems like a reasonable change, then.

Does this give fully-qualified names for types defined in namespaces,
too?  I don't have GCC 3.3 lying around and I'm not familiar enough
with GCC to be able to tell from the patch.

David Carlton
carlton@kealia.com

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

[Kevin Buettner]

On Jul 2, 12:19pm, David Carlton wrote:

> On Wed, 2 Jul 2003 12:02:33 -0700, Kevin Buettner <kevinb@redhat.com> said:
> 
> > See
> 
> >     http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01715.html
> 
> > (where I explain the motivation behind this change).
> 
> Ah, thanks.  That seems like a reasonable change, then.
> 
> Does this give fully-qualified names for types defined in namespaces,
> too?

I don't think so, but I'm really not sure.  My recollection is that an
early version of the patch did this, but I was convinced to remove the
namespace bit of it.  I'm not sure why any more.

I've been hunting around for the original patch that supported
namespaces.  (It won't appear in any mailing lists external to Red
Hat.) I've found one that predates the one that finally got committed,
but I can't see why one of these would support namespaces and the
other not.

I guess the answer is, "Try it and let me know..."

Kevin

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

[Michael Elizabeth Chastain]

drow> Could you try adding the .* from the following (kfail) pattern instead? 
drow> I.E. right after "int x;".

Mmmm, no.  I don't like ".*" in a PASS pattern.

I admit it's kind of yucky to be too specific, but the yuckiness
manifests as new FAILs when new compilers come out, which I can
handle.  With "int x;.*\\}" { pass ... }, we will get spurious
passes if gcc or gdb breaks.

Michael C

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

[Michael Elizabeth Chastain]

This patch adds a pattern to a ptype test in classes.exp.

Here is the story.  The class is:

  class ClassWithEnum {
  public:
    enum PrivEnum { red, green, blue, yellow = 42 };
    PrivEnum priv_enum;
    int x;
  };

The ptype output depends on the compiler version and the debugging
format.  Here are all ten of them:

  # gcc 2.95.3         -gdwarf-2
  # gcc 3.2.3          -gdwarf-2
  # gcc 3.3            -gdwarf-2
  # gcc gcc-3_3-branch -gdwarf-2

    ptype obj_with_enum
    type = class ClassWithEnum {
      public:
	PrivEnum priv_enum;
	int x;
    }
    (gdb) KFAIL: gdb.c++/classes.exp: ptype obj_with_enum (PRMS: gdb/57)

  # gdb HEAD -gdwarf-2

    ptype obj_with_enum
    No symbol "obj_with_enum" in current context.
    (gdb) FAIL: gdb.c++/classes.exp: ptype obj_with_enum

  # gcc 2.95.3 -gstabs+
  # gcc 3.2.3  -gstabs+

    ptype obj_with_enum
    type = class ClassWithEnum {
      public:
	PrivEnum priv_enum;
	int x;
    
	ClassWithEnum & operator=(ClassWithEnum const &);
	ClassWithEnum(ClassWithEnum const &);
	ClassWithEnum(void);
    }
    (gdb) KFAIL: gdb.c++/classes.exp: ptype obj_with_enum (PRMS: gdb/57)

  # gcc 3.3            -gstabs+
  # gcc gcc-3_3-branch -gstabs+
  # gcc HEAD           -gstabs+

    ptype obj_with_enum
    type = class ClassWithEnum {
      public:
	ClassWithEnum::PrivEnum priv_enum;
	int x;
    
	ClassWithEnum & operator=(ClassWithEnum const&);
	ClassWithEnum(ClassWithEnum const&);
	ClassWithEnum();
    }
    (gdb) FAIL: gdb.c++/classes.exp: ptype obj_with_enum

Grubbing through all these configurations fatigues the brain!

So ... the configurations with KFAIL are cool.  David C left a comment
in the test script indicating that naked 'PrivEnum' is a symptomm of a
gdb bug.

The configuration gcc HEAD -gdwarf-2 points to a real bug which needs
investigation.

My concern is gcc 3.3 -gstabs+.  gdb is printing the right output, but
there is no arm in the test case for it, so it FAILed.  This patch adds
an arm so that this output will now PASS.

Testing: tested on HEAD with all the compilers and debug formats shown,
native i686-pc-linux-gnu.

I will apply this tomorrow to HEAD if nobody has an objection, and
backport it to gdb_6_0-branch some time after that.

(This is item #2 on my three item list to fix all the places where
gcc 3.3 has regressions versus gcc 3.2.3).

Michael C

2003-07-02  Michael Chastain  <mec@shout.net>

	* gdb.c++/classes.exp (test_enums): Accept ptype output that
	shows compiler-generated functions.

Index: classes.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/classes.exp,v
retrieving revision 1.17
diff -u -r1.17 classes.exp
--- classes.exp	3 Mar 2003 18:48:31 -0000	1.17
+++ classes.exp	2 Jul 2003 15:20:43 -0000
@@ -659,7 +659,12 @@
     # ptype on the object
     send_gdb "ptype obj_with_enum\n"
     gdb_expect {
-	-re "type = class ClassWithEnum \\{\r\n\[ \t\]*public:\r\n\[ \t\]*(enum |)ClassWithEnum::PrivEnum priv_enum;\r\n\[ \t\]*int x;\r\n\\}\r\n$gdb_prompt $" { pass "ptype obj_with_enum" }
+	-re "type = class ClassWithEnum \\{\r\n\[ \t\]*public:\r\n\[ \t\]*(enum |)ClassWithEnum::PrivEnum priv_enum;\r\n\[ \t\]*int x;\r\n\\}\r\n$gdb_prompt $" {
+	    pass "ptype obj_with_enum"
+	}
+	-re "type = class ClassWithEnum \\{\r\n\[ \t\]*public:\r\n\[ \t\]*(enum |)ClassWithEnum::PrivEnum priv_enum;\r\n\[ \t\]*int x;\[\r\n\]+\[ \t\]*ClassWithEnum *& *operator *=\\(ClassWithEnum const *&\\);\r\n\[ \t\]*ClassWithEnum\\(ClassWithEnum const *&\\);\r\n\[ \t\]*ClassWithEnum\\( *\\);\r\n\\}\r\n$gdb_prompt $" {
+	    pass "ptype obj_with_enum"
+	}
 	-re "type = class ClassWithEnum \\{\r\n\[ \t\]*public:\r\n\[ \t\]*(enum |)PrivEnum priv_enum;\r\n\[ \t\]*int x;.*\\}\r\n$gdb_prompt $"
 	{
 	    # NOTE: carlton/2003-02-28: One could certainly argue that

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

[Daniel Jacobowitz]

On Wed, Jul 02, 2003 at 11:39:19AM -0400, Michael Elizabeth Chastain wrote:
> This patch adds a pattern to a ptype test in classes.exp.
> 
> Here is the story.  The class is:
> 
>   class ClassWithEnum {
>   public:
>     enum PrivEnum { red, green, blue, yellow = 42 };
>     PrivEnum priv_enum;
>     int x;
>   };

> My concern is gcc 3.3 -gstabs+.  gdb is printing the right output, but
> there is no arm in the test case for it, so it FAILed.  This patch adds
> an arm so that this output will now PASS.

Could you try adding the .* from the following (kfail) pattern instead? 
I.E. right after "int x;".

We'll have to revisit this someday.  Eventually, I want that KFAIL'ing
pattern to be the correct output.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[David Carlton]

On Wed, 2 Jul 2003 11:39:19 -0400, Michael Elizabeth Chastain
<mec@shout.net> said:

>   # gcc 3.3            -gstabs+
>   # gcc gcc-3_3-branch -gstabs+
>   # gcc HEAD           -gstabs+

>     ptype obj_with_enum
>     type = class ClassWithEnum {
>       public:
> 	ClassWithEnum::PrivEnum priv_enum;
> 	int x;
    
> 	ClassWithEnum & operator=(ClassWithEnum const&);
> 	ClassWithEnum(ClassWithEnum const&);
> 	ClassWithEnum();
>     }
>     (gdb) FAIL: gdb.c++/classes.exp: ptype obj_with_enum

Sigh.  Do the GCC stabs maintainers just randomly change their output
to keep us on our toes, or what?  Maybe I shouldn't be annoyed, given
that that output is actually what we (eventually) _want_ GDB to be
producing, but if we want stabs debugging to work well, we need to sit
down and figure out what names stabs should list for various types,
and we need GCC to stick with whatever that decision might be.

I'm happy enough with your patch, but I'd prefer a comment at the
beginning of the test noting that it only passes by accident:
something like

# NOTE: carlton/2003-07-02: Currently, this test only passes with GCC
# 3.3 and higher and with -gstabs+, and it only passes in those
# situations by accident.

David Carlton
carlton@kealia.com