Re: [rfc] xfailed tests in gdb.c++/classes.exp

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Michael Elizabeth Chastain]

dc> 1) GDB prints "class X { public: ... }" when the programmer originally
dc>    wrote "struct X { ... }".

I think this should be a PASS.

dc> 2) GDB prints "class X { private: int x; ... }" when the programmer
dc>    originally wrote "class X { int x; ... }".

I think this should be a PASS.

David C formulated this idea as: if the text can be fed back into a C++
compiler and generate the same results, then it's okay.  By and large I
agree with that.

If you look in gnats, you will see users complaining that they can't
print their string variables (because C++ strings are implemented with
layers of templates and derived classes).  They are complaining that
operator overloading doesn't work.  They are complaining that they have
a std::vector<Foo> and they can't even look inside the damn thing.

They aren't complaining that they wrote 'struct X { ... }' but gdb
prints 'class X { public: ... }'.

Michael C

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Daniel Jacobowitz]

On Thu, Feb 27, 2003 at 09:51:06PM -0600, Michael Elizabeth Chastain wrote:
> dc> 1) GDB prints "class X { public: ... }" when the programmer originally
> dc>    wrote "struct X { ... }".
> 
> I think this should be a PASS.
> 
> dc> 2) GDB prints "class X { private: int x; ... }" when the programmer
> dc>    originally wrote "class X { int x; ... }".
> 
> I think this should be a PASS.
> 
> David C formulated this idea as: if the text can be fed back into a C++
> compiler and generate the same results, then it's okay.  By and large I
> agree with that.
> 
> If you look in gnats, you will see users complaining that they can't
> print their string variables (because C++ strings are implemented with
> layers of templates and derived classes).  They are complaining that
> operator overloading doesn't work.  They are complaining that they have
> a std::vector<Foo> and they can't even look inside the damn thing.
> 
> They aren't complaining that they wrote 'struct X { ... }' but gdb
> prints 'class X { public: ... }'.

Sure.  But I suspect 2) represents an actual bug.  Fixing this is about
three lines in c-typeprint.c.  Should we or shouldn't we?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> On Thu, Feb 27, 2003 at 09:51:06PM -0600, Michael Elizabeth
 Daniel> Chastain wrote:
 dc> 1) GDB prints "class X { public: ... }" when the programmer
 dc> originally wrote "struct X { ... }".
 >> I think this should be a PASS.
 >> 
 dc> 2) GDB prints "class X { private: int x; ... }" when the
 dc> programmer originally wrote "class X { int x; ... }".
 >> I think this should be a PASS.
 >> 
 >> David C formulated this idea as: if the text can be fed back into
 >> a C++ compiler and generate the same results, then it's okay.  By
 >> and large I agree with that.
 >> 
 >> If you look in gnats, you will see users complaining that they
 >> can't print their string variables (because C++ strings are
 >> implemented with layers of templates and derived classes).  They
 >> are complaining that operator overloading doesn't work.  They are
 >> complaining that they have a std::vector<Foo> and they can't even
 >> look inside the damn thing.
 >> 
 >> They aren't complaining that they wrote 'struct X { ... }' but gdb
 >> prints 'class X { public: ... }'.

 Daniel> Sure.  But I suspect 2) represents an actual bug.  Fixing
 Daniel> this is about three lines in c-typeprint.c.  Should we or
 Daniel> shouldn't we?

Why?  In both cases, the source code text and the GDB printout are
equivalent by the C++ rules.  You can replace the one by the other
without any impact on the meaning of the program.

Certainly for those who are only half conversant with C++ type rules,
having "struct foo" replaced by "class foo { public:" may come as a
surprise, but that's a good incentive for them to learn the
language...

	paul

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Jason Molenda]

I like to pull mail threads utterly off-topic whenever possible:

On Thursday, February 27, 2003, at 07:51  PM, Michael Elizabeth 
Chastain wrote:

> If you look in gnats, you will see users complaining that they can't
> print their string variables (because C++ strings are implemented with
> layers of templates and derived classes).  They are complaining that
> operator overloading doesn't work.  They are complaining that they have
> a std::vector<Foo> and they can't even look inside the damn thing.

We have the same problem here at Apple, introspecting objects.  As a 
convention, many of the standard Cocoa Objective C classes include a 
"NSPrintForDebugger" member function which can print the object in some 
way that is meaningful to the developer.  We have a gdb command, 
"print-object" or "po" which does an inferior function call into this.  
In the GUI, we let users right-click on locals et al and do this 
command.  It's not fancy/seamless/beautiful, but it is enough for users 
to do what they need.  It does depend on support from the class 
libraries, obviously.

That's still not ideal - your Locals window still shows a bunch of 
variables with raw pointers instead of the strings they contain.  Rab 
Hagy added a feature last summer to display these objects as strings 
when using the ProjectBuilder GUI.  He added a solib that is loaded 
into the inferior to provide some object introspection functions in the 
inferior executable, and at a stop he determines if an object is an 
NSString class or inherited from that class, and then gets the 
formatted version of that text.

This approach is very expensive (making an inferior function call for 
each local object for each step) so we'll surely need to refine it in 
the future, but it's a step in the right direction.


Well, Rab could provide better details on what he did and where he sees 
this going (I was utterly uninvolved), but we're looking at these same 
problems here at Apple.  We haven't cracked into the C++ library yet, 
but the problems are of a similar sort.

J

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[David Carlton]

On Fri, 28 Feb 2003 10:15:21 -0500, Daniel Jacobowitz <drow@mvista.com> said:

> The consensus is obviously that this output is OK.  David, please do
> add the new pass patterns.

Done; patch below.  Interestingly, it turns out that some of the
'ptype class/struct' tests in that file also contained setup_xfails
that should be treated as FAIL as well as treated as PASS (accepting
structs with missing protected/private protection specifiers); I
deleted those setup_xfail lines, too, but left those tests as FAIL.
(GDB currently passes the tests in question.)

I'd also forgotten that there were XFAILs in there that I actually am
seeing that weren't related to this issue: yet another instance of the
nested types bug.  I'll prepare a patch for that shortly.

(Whoops: reading the patch below, I got class public_class slightly
wrong; I'll commit another patch for that in a sec.)

David Carlton
carlton@math.stanford.edu

2003-02-28  David Carlton  <carlton@math.stanford.edu>

	* gdb.c++/classes.exp (test_ptype_class_objects): Accept it if we
	print class instead of struct and/or superfluous protection
	specifiers, as long as the resulting output is equivalent to the
	source code.
	Delete FIXME from end of messages on tests that don't need
	fixing.

Index: classes.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/classes.exp,v
retrieving revision 1.14
diff -u -p -r1.14 classes.exp
--- classes.exp	13 Feb 2003 21:33:20 -0000	1.14
+++ classes.exp	28 Feb 2003 17:44:14 -0000
@@ -55,7 +55,7 @@ proc test_ptype_class_objects {} {
 
     # Note that struct members are public by default, so we don't print
     # "public:" for the public members of structs.
-    # Accept it as an expected failure if gdb just fails to distinguish between
+    # Accept it if gdb just fails to distinguish between
     # class and struct, and everything else is OK.
 
     send_gdb "ptype struct default_public_struct\n"
@@ -64,8 +64,7 @@ proc test_ptype_class_objects {} {
 	    pass "ptype struct default_public_struct"
 	}
 	-re "type = class default_public_struct \{$nl.*int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
-	    fail "ptype struct default_public_struct"
+	    pass "ptype struct default_public_struct"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype struct default_public_struct" }
 	timeout { fail "ptype struct default_public_struct (timeout)" ; return }
@@ -73,7 +72,7 @@ proc test_ptype_class_objects {} {
 
     # Note that struct members are public by default, so we don't print
     # "public:" for the public members of structs.
-    # Accept it as an expected failure if gdb just fails to distinguish between
+    # Accept it if gdb just fails to distinguish between
     # class and struct, and everything else is OK.
 
     send_gdb "ptype struct explicit_public_struct\n"
@@ -82,75 +81,70 @@ proc test_ptype_class_objects {} {
 	    pass "ptype struct explicit_public_struct"
 	}
 	-re "type = class explicit_public_struct \{$nl.*int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
-	    fail "ptype struct explicit_public_struct"
+	    pass "ptype struct explicit_public_struct"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype struct explicit_public_struct" }
 	timeout { fail "ptype struct explicit_public_struct (timeout)" ; return }
     }
 
-    # Accept it as an expected failure if gdb just fails to distinguish between
+    # Accept it if gdb just fails to distinguish between
     # class and struct, and everything else is OK.
 
     send_gdb "ptype struct protected_struct\n"
     gdb_expect {
 	-re "type = struct protected_struct \{${ws}protected:${ws}int a;${ws}int b;$nl\}$nl$gdb_prompt $" {
-	    pass "ptype struct protected_struct (FIXME)"
+	    pass "ptype struct protected_struct"
 	}
 	-re "type = class protected_struct \{${ws}protected:${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
-	    fail "ptype struct protected_struct (FIXME)"
+	    pass "ptype struct protected_struct"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype struct protected_struct" }
 	timeout { fail "ptype struct protected_struct (timeout)" ; return }
     }
 
-    # Accept it as an expected failure if gdb just fails to distinguish between
+    # Accept it if gdb just fails to distinguish between
     # class and struct, and everything else is OK.
 
     send_gdb "ptype struct private_struct\n"
     gdb_expect {
 	-re "type = struct private_struct \{${ws}private:${ws}int a;${ws}int b;$nl\}$nl$gdb_prompt $" {
-	    pass "ptype struct private_struct (FIXME)"
+	    pass "ptype struct private_struct"
 	}
 	-re "type = class private_struct \{${ws}private:${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" { 
-	    setup_xfail "*-*-*"
-	    fail "ptype struct private_struct (FIXME)"
+	    pass "ptype struct private_struct"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype struct private_struct" }
 	timeout { fail "ptype struct private_struct (timeout)" ; return }
     }
 
-    # Accept it as an expected failure if gdb just fails to distinguish between
+    # Accept it if gdb just fails to distinguish between
     # class and struct, and everything else is OK.
 
     send_gdb "ptype struct mixed_protection_struct\n"
     gdb_expect {
 	-re "type = struct mixed_protection_struct \{${ws}int a;${ws}int b;${ws}private:${ws}int c;${ws}int d;${ws}protected:${ws}int e;${ws}int f;${ws}public:${ws}int g;${ws}private:${ws}int h;${ws}protected:${ws}int i;$nl\}$nl$gdb_prompt $" {
-	    pass "ptype struct mixed_protection_struct (FIXME)"
+	    pass "ptype struct mixed_protection_struct"
 	}
         -re "type = struct mixed_protection_struct \{${ws}public:${ws}int a;${ws}int b;${ws}private:${ws}int c;${ws}int d;${ws}protected:${ws}int e;${ws}int f;${ws}public:${ws}int g;${ws}private:${ws}int h;${ws}protected:${ws}int i;$nl.*\}$nl$gdb_prompt $" {
             pass "ptype struct mixed_protection_struct (extra public)"
         }
 	-re "type = class mixed_protection_struct \{${ws}public:${ws}int a;${ws}int b;${ws}private:${ws}int c;${ws}int d;${ws}protected:${ws}int e;${ws}int f;${ws}public:${ws}int g;${ws}private:${ws}int h;${ws}protected:${ws}int i;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
-	    fail "ptype struct mixed_protection_struct (FIXME)"
+	    pass "ptype struct mixed_protection_struct"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype struct mixed_protection_struct" }
 	timeout { fail "ptype struct mixed_protection_struct (timeout)" ; return }
     }
 
-    # Accept it as an expected failure if gdb just fails to distinguish between
+    # Accept it if gdb just fails to distinguish between
     # class and struct, and everything else is OK.
 
     send_gdb "ptype class public_class\n"
     gdb_expect {
 	-re "type = class public_class \{${ws}public:${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    pass "ptype class public_class (FIXME)"
+	    pass "ptype class public_class"
 	}
 	-re "type = struct public_class \{${ws}int a;${ws}int b;$nl\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
-	    fail "ptype class public_class (FIXME)"
+	    fail "ptype class public_class"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype class public_class" }
 	timeout { fail "ptype class public_class (timeout)" ; return }
@@ -162,14 +156,13 @@ proc test_ptype_class_objects {} {
 	    pass "ptype class protected_class"
 	}
 	-re "type = struct protected_class \{${ws}int a;${ws}int b;$nl\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
 	    fail "ptype class protected_class"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype class protected_class" }
 	timeout { fail "ptype class protected_class (timeout)" ; return }
     }
 
-    # Accept it as an expected failure if gdb just emits a superflous "private:"
+    # Accept it if gdb just emits a superflous "private:"
     # attribute, since classes default to private and for consistency with
     # structs (where we don't print the "public:" attribute) we don't print
     # the "private:" attribute.
@@ -177,11 +170,10 @@ proc test_ptype_class_objects {} {
     send_gdb "ptype class default_private_class\n"
     gdb_expect {
 	-re "type = class default_private_class \{${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    pass "ptype class default_private_class (FIXME)"
+	    pass "ptype class default_private_class"
 	}
 	-re "type = class default_private_class \{${ws}private:${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
-	    fail "ptype class default_private_class (FIXME)"
+	    pass "ptype class default_private_class"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype class default_private_class" }
 	timeout { fail "ptype class default_private_class (timeout)" ; return }
@@ -193,10 +185,9 @@ proc test_ptype_class_objects {} {
 	    pass "ptype class explicit_private_class"
 	}
         -re "type = class explicit_private_class \{${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-            pass "ptype class explicit_private_class (OK for HP aCC)"
+            pass "ptype class explicit_private_class"
         }
 	-re "type = struct explicit_private_class \{${ws}int a;${ws}int b;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
 	    fail "ptype class explicit_private_class"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype class explicit_private_class" }
@@ -209,7 +200,6 @@ proc test_ptype_class_objects {} {
 	    pass "ptype class mixed_protection_class"
 	}
 	-re "type = struct mixed_protection_class \{${ws}int a;${ws}int b;${ws}int c;${ws}int d;${ws}int e;${ws}int f;${ws}int g;${ws}int h;${ws}int i;$nl.*\}$nl$gdb_prompt $" {
-	    setup_xfail "*-*-*"
 	    fail "ptype class mixed_protection_class"
 	}
 	-re ".*$gdb_prompt $" { fail "ptype class mixed_protection_class" }

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Daniel Jacobowitz]

On Thu, Feb 27, 2003 at 11:01:50PM -0600, Michael Elizabeth Chastain wrote:
> > Sure.  But I suspect 2) represents an actual bug.  Fixing this is about
> > three lines in c-typeprint.c.  Should we or shouldn't we?
> 
> A little late night rambling ...
> 
> It depends on your role.
> 
> In the QA role I've got kind of a black-boxy view.  If the test script
> mimics what a user would type, and if I think that most users would be
> happy, then I'm happy.
> 
> In the developer role, any loose edge might be a symptom of a bug.  I
> remember when one little test in selftest.exp did not pass and I traced
> it down to memory corruption inside gdb.  And we all know that a stitch
> in time saves nine.  If you're looking at results that don't match what
> you, as a developer, believe the code should do, that is noteworthy,
> even if Joe User has no issue with it.
> 
> Also, gdb has thousands more problems than we can fix.  We have to do
> brutal triage on our TODO lists, every day.  And I am personally bad at
> prioritizing.  In fact one of my motives for working on gdb is to
> practice better prioritizing in an environment that lets me set my own
> goals.

The consensus is obviously that this output is OK.  David, please do
add the new pass patterns.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Michael Elizabeth Chastain]

> Sure.  But I suspect 2) represents an actual bug.  Fixing this is about
> three lines in c-typeprint.c.  Should we or shouldn't we?

A little late night rambling ...

It depends on your role.

In the QA role I've got kind of a black-boxy view.  If the test script
mimics what a user would type, and if I think that most users would be
happy, then I'm happy.

In the developer role, any loose edge might be a symptom of a bug.  I
remember when one little test in selftest.exp did not pass and I traced
it down to memory corruption inside gdb.  And we all know that a stitch
in time saves nine.  If you're looking at results that don't match what
you, as a developer, believe the code should do, that is noteworthy,
even if Joe User has no issue with it.

Also, gdb has thousands more problems than we can fix.  We have to do
brutal triage on our TODO lists, every day.  And I am personally bad at
prioritizing.  In fact one of my motives for working on gdb is to
practice better prioritizing in an environment that lets me set my own
goals.

Michael C

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Daniel Jacobowitz]

Sorry for losing this message (again).

On Fri, Jan 03, 2003 at 02:53:00PM -0800, David Carlton wrote:
> I've been looking at the xfailed tests in gdb.c++/classes.exp, and
> some of the xfails aren't too convincing.  Specifically, the tests
> that I'm looking at do ptypes of C++ data structures, and several of
> the xfails fall into one or both of these categories:
> 
> 1) GDB prints "class X { public: ... }" when the programmer originally
>    wrote "struct X { ... }".

Hmm, this should definitely be eiter a pass or an XFAIL.  If you want
to let it pass, I'm fine with that decision.

> 2) GDB prints "class X { private: int x; ... }" when the programmer
>    originally wrote "class X { int x; ... }".

This should either be a PASS or be corrected.  Do you think that it's
more logical to print it as above or should we just elide the private?

I think we have already got logic to do this, so it might be an
outright bug that we don't.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Michael Elizabeth Chastain]

> 1) GDB prints "class X { public: ... }" when the programmer originally
>    wrote "struct X { ... }".

We talked about this about two years ago, and the consensus was
that this is a bug in gdb.  I did not agree with that consensus.

> 2) GDB prints "class X { private: int x; ... }" when the programmer
>    originally wrote "class X { int x; ... }".

I don't recall discussing this in particular.

> The arguments for treating them as passes is as follows: GDB's goal
> isn't to print out exactly what the programmer typed: it's to print
> out a type that's equivalent to what the programmer typed, one that
> gives all the information that the programmer needs.

I believe in this.

> And, in both of the cases above, programmers could replace their
> definitions by the definitions that GDB prints out without changing the
> behavior of their programs.

I believe this is a good operational test.

As a user, it's perfectly fine with me that GDB canonicalizes the
class/struct when printing it out.  It's vital that GDB prints
_correct_ information.  It's important that GDB prints _complete_
information.  We have so many problems at this level with C++,
it's a crying shame that we devote bug-handling resources to
"class X { public: ... }".

> Personally, I'd treat both these cases as passes.  On the other hand,
> Daniel's the C++ maintainer; if he thinks one or both of these cases
> should be considered a bug in GDB, then I'll file PR's and KFAIL them
> as appropriate.

Ditto.

Michael C

[rfc] xfailed tests in gdb.c++/classes.exp

[David Carlton]

I've been looking at the xfailed tests in gdb.c++/classes.exp, and
some of the xfails aren't too convincing.  Specifically, the tests
that I'm looking at do ptypes of C++ data structures, and several of
the xfails fall into one or both of these categories:

1) GDB prints "class X { public: ... }" when the programmer originally
   wrote "struct X { ... }".

2) GDB prints "class X { private: int x; ... }" when the programmer
   originally wrote "class X { int x; ... }".

My question is: should we consider these as GDB bugs, or not?  In
other words, should I change the xfails to kfails, or should I change
them to passes?

The arguments for treating them as passes is as follows: GDB's goal
isn't to print out exactly what the programmer typed: it's to print
out a type that's equivalent to what the programmer typed, one that
gives all the information that the programmer needs.  So it would be
ridiculous, for example, to call it a bug in GDB if GDB didn't exactly
replicate the whitespace in a definition.  And, in both of the cases
above, programmers could replace their definitions by the definitions
that GDB prints out without changing the behavior of their programs.
Stroustrup says: "By definition, a struct is a class in which members
are by default public"; and just because members of a class are, by
default, private doesn't mean that there's anything wrong with making
that default explicit.

The arguments for treating them as failures are that DWARF 2 does, in
fact, contain enough information to be able to recover the data that
we're ignoring.  (GCC doesn't emit it, at least in case 1, but never
mind that.)  And, while changing all instances of "struct X { ... }"
to "class X { public: ... }" is behavior-preserving, changing one
instance might violate the one definition rule, so the two versions
aren't really the same for sufficiently pedantic definitions of "the
same".

Personally, I'd treat both these cases as passes.  On the other hand,
Daniel's the C++ maintainer; if he thinks one or both of these cases
should be considered a bug in GDB, then I'll file PR's and KFAIL them
as appropriate.

Opinions?

David Carlton
carlton@math.stanford.edu