Re: Pinging Michael C

Re: Pinging Michael C

[Michael Elizabeth Chastain]

I've been inactive since May, and I'll be inactive for probably another
couple of months.  I will always be at this address.  I do plan to come
back but if someone else can pick up the C++ testsuite stuff I will be
grateful.

Michael C

Pinging Michael C

[Daniel Jacobowitz]

Michael,

Are you still around and at this address?  I haven't heard from you in some
time, and David Carlton's C++ testsuite patches from August are still
awaiting review:
  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html
  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00472.html
  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00469.html

As is one of Jim Blandy's:
  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00670.html

[The Sunday Project doesn't seem to have been updated since the end of May,
either.]

I'm about to do a couple of very drastic things to the output of the C++
type printer, and there's going to be a lot of testsuite traffic to go with
them.  If you no longer have time for GDB, I can ask someone else
(Fernando?) to approve them, but I wanted to check with you first.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pinging Michael C

[Fernando Nasser]

I am assuming you all have looked at the C++ side of these tests...

Daniel Jacobowitz wrote:
> Michael,
> 
> Are you still around and at this address?  I haven't heard from you in some
> time, and David Carlton's C++ testsuite patches from August are still
> awaiting review:
>   http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html

I wonder if next will relly be more reliable.  Anyway, we can try -- the 
test is not about breakpoints.

The following ChangeLog entries need some more info though:

	* gdb.c++/m-static.cc: Add test 4.
	* gdb.c++/m-static.h: New file.
	* gdb.c++/m-static1.cc: New file.


>   http://sources.redhat.com/ml/gdb-patches/2002-08/msg00472.html

I don't think we want to add tests to make gdb dump core to the 
testsuite right away.  It should go in as soon as someone fixes the 
problem to prevent a regression.  Alternatively we can add it in and 
explicitly skip the test with a explicit call to the kfail proc...

I don't see anything wrong with the test file itself, but the ChangeLog 
also needs some more info (what the new files do/test).

	* gdb.c++/printmethod.exp: New file.
	* gdb.c++/printmethod.cc: New file.


>   http://sources.redhat.com/ml/gdb-patches/2002-08/msg00469.html
> 

I was talking to Andrew about collecting these regression tests into a 
single file (someone would eventually move them into one of the other 
files if the test can be associated with some feature).

Andrew, what was the name of the file? I forgot...

Again, the test s OK but the ChangeLog entries need more info.
P.S.: If this is not fixed yet please use setup_kfail and refer to 
appropriate Gnats bug report.



> As is one of Jim Blandy's:
>   http://sources.redhat.com/ml/gdb-patches/2002-08/msg00670.html

Nice!  Just needs a correct ChangeLog entry in the proper format and at 
least mentioning what the new tests are for (although one could guess 
from the file names, but we don't usually rely on that).


Regards to all,
Fernando

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Pinging Michael C

[Daniel Jacobowitz]

On Mon, Sep 16, 2002 at 10:55:47AM -0400, Fernando Nasser wrote:
> I am assuming you all have looked at the C++ side of these tests...

I hadn't given them enough attention, but now I have...

> Daniel Jacobowitz wrote:
> >Michael,
> >
> >Are you still around and at this address?  I haven't heard from you in some
> >time, and David Carlton's C++ testsuite patches from August are still
> >awaiting review:
> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html
> 
> I wonder if next will relly be more reliable.  Anyway, we can try -- the 
> test is not about breakpoints.

I hadn't actually looked at this one.  David, there's an easier way -
if you look in lib/gdb.exp, gdb_get_line_number.  Is that closer to
what you want?  It should be more reliable than 'next'ing.

> The following ChangeLog entries need some more info though:
> 
> 	* gdb.c++/m-static.cc: Add test 4.
> 	* gdb.c++/m-static.h: New file.
> 	* gdb.c++/m-static1.cc: New file.

(Fernando, this is exactly what the GNU coding standards say a
ChangeLog entry should look like - just what changed, not why it was
changed, which belongs only in the code.  What else are you looking
for?)

> 
> 
> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00472.html
> 
> I don't think we want to add tests to make gdb dump core to the 
> testsuite right away.  It should go in as soon as someone fixes the 
> problem to prevent a regression.  Alternatively we can add it in and 
> explicitly skip the test with a explicit call to the kfail proc...

Fortunately, David has since fixed the bug.  I think this patch is
ready to go in, once we agree on ChangeLog formatting.

> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00469.html
> >
> 
> I was talking to Andrew about collecting these regression tests into a 
> single file (someone would eventually move them into one of the other 
> files if the test can be associated with some feature).
> 
> Andrew, what was the name of the file? I forgot...

I have an even better idea (I think :).  I'll post an RFC for it in a
second.

> Again, the test s OK but the ChangeLog entries need more info.
> P.S.: If this is not fixed yet please use setup_kfail and refer to 
> appropriate Gnats bug report.

Test looks fine to me from the C++ side, with setup_kfail if necessary.

> >As is one of Jim Blandy's:
> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00670.html
> 
> Nice!  Just needs a correct ChangeLog entry in the proper format and at 
> least mentioning what the new tests are for (although one could guess 
> from the file names, but we don't usually rely on that).

Also looks good.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pinging Michael C

[Fernando Nasser]

Daniel Jacobowitz wrote:
>>	* gdb.c++/m-static.cc: Add test 4.
>>	* gdb.c++/m-static.h: New file.
>>	* gdb.c++/m-static1.cc: New file.
> 
> 
> (Fernando, this is exactly what the GNU coding standards say a
> ChangeLog entry should look like - just what changed, not why it was
> changed, which belongs only in the code.  What else are you looking
> for?)
> 

Just what the new file is for/what it does.

Like:

        * gcore.c: New file.  Implement new command 'generate-core-file'.


But now I see that this is not being enforced lately. I liked that 
feature. :-(



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Pinging Michael C

[David Carlton]

On Mon, 16 Sep 2002 11:09:21 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Mon, Sep 16, 2002 at 10:55:47AM -0400, Fernando Nasser wrote:
>> Daniel Jacobowitz wrote:

>>> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html

>> I wonder if next will relly be more reliable.  Anyway, we can try
>> -- the test is not about breakpoints.

> I hadn't actually looked at this one.  David, there's an easier way
> - if you look in lib/gdb.exp, gdb_get_line_number.  Is that closer
> to what you want?  It should be more reliable than 'next'ing.

Honestly, I don't know if either of them is reliable, as is written.
The situation is that m-static.cc constructs a bunch of objects that
it doesn't do anything with; m-static.exp tries to stop after each
object is constructed, and then examine what the object looks like.

And it seems to me that, whether you use next or breakpoints (and
whether you do the latter with hard-coded numbers (blech), relative
offsets, or with gdb_get_line_number), you're going to run into
problems in that GDB might not be willing to stop at every line, and
that whether or not it is willing might depend on the specific
compiler, compiler options, etc. that are being used.

Personally, I don't see any reason why the test shouldn't just
construct all the objects before inspecting any of them with GDB.  So
what makes sense to me would be to put a breakpoint on the return line
(using gdb_get_line_number, presumably), run until that, and only then
inspect all the objects that have been constructed.

But if people don't like that, I'd prefer to stick with the current
next'ing (with a break +2 throw in for fun).  I think that would be as
reliable and easier to maintain than gdb_get_line_number.  The latter
only makes sense if people might later insert lines that should be
skipped in the middle of the extant constructors; that doesn't seem
too plausible to me.

>> The following ChangeLog entries need some more info though:
>> 
>> * gdb.c++/m-static.cc: Add test 4.
>> * gdb.c++/m-static.h: New file.
>> * gdb.c++/m-static1.cc: New file.

> (Fernando, this is exactly what the GNU coding standards say a
> ChangeLog entry should look like - just what changed, not why it was
> changed, which belongs only in the code.  What else are you looking
> for?)

I don't mind making them longer, but Andrew yells at me whenever I
include long comments.  So I'd rather not make the ChangeLog entries
more verbose without hearing from him first.

>> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00472.html

>> I don't think we want to add tests to make gdb dump core to the 
>> testsuite right away.  It should go in as soon as someone fixes the 
>> problem to prevent a regression.  Alternatively we can add it in and 
>> explicitly skip the test with a explicit call to the kfail proc...

> Fortunately, David has since fixed the bug.  I think this patch is
> ready to go in, once we agree on ChangeLog formatting.

Right, and of course I'll update the comment in the .exp file
accordingly.


So would it be okay if I changed the test with all the next's to
construct all the objects before examining any of them, updated the
comments on the one test to reflect the fact that the bug has been
fixed, and then check them in?

David Carlton
carlton@math.stanford.edu

Re: Pinging Michael C

[Daniel Jacobowitz]

On Mon, Sep 16, 2002 at 10:03:16AM -0700, David Carlton wrote:
> On Mon, 16 Sep 2002 11:09:21 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> > On Mon, Sep 16, 2002 at 10:55:47AM -0400, Fernando Nasser wrote:
> >> Daniel Jacobowitz wrote:
> 
> >>> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html
> 
> >> I wonder if next will relly be more reliable.  Anyway, we can try
> >> -- the test is not about breakpoints.
> 
> > I hadn't actually looked at this one.  David, there's an easier way
> > - if you look in lib/gdb.exp, gdb_get_line_number.  Is that closer
> > to what you want?  It should be more reliable than 'next'ing.
> 
> Honestly, I don't know if either of them is reliable, as is written.
> The situation is that m-static.cc constructs a bunch of objects that
> it doesn't do anything with; m-static.exp tries to stop after each
> object is constructed, and then examine what the object looks like.
> 
> And it seems to me that, whether you use next or breakpoints (and
> whether you do the latter with hard-coded numbers (blech), relative
> offsets, or with gdb_get_line_number), you're going to run into
> problems in that GDB might not be willing to stop at every line, and
> that whether or not it is willing might depend on the specific
> compiler, compiler options, etc. that are being used.
> 
> Personally, I don't see any reason why the test shouldn't just
> construct all the objects before inspecting any of them with GDB.  So
> what makes sense to me would be to put a breakpoint on the return line
> (using gdb_get_line_number, presumably), run until that, and only then
> inspect all the objects that have been constructed.

I like this.  Would you mind doing it that way?  It's much less
error-prone.

> So would it be okay if I changed the test with all the next's to
> construct all the objects before examining any of them, updated the
> comments on the one test to reflect the fact that the bug has been
> fixed, and then check them in?

Well, I think Fernando has approved the testsuite-side and I'm fine
with the C++ of the tests.  I'd say yes.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pinging Michael C

[David Carlton]

On Mon, 16 Sep 2002 13:11:50 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Mon, Sep 16, 2002 at 10:03:16AM -0700, David Carlton wrote:

>> So would it be okay if I changed the test with all the next's to
>> construct all the objects before examining any of them, updated the
>> comments on the one test to reflect the fact that the bug has been
>> fixed, and then check them in?

> Well, I think Fernando has approved the testsuite-side and I'm fine
> with the C++ of the tests.  I'd say yes.

Great.  I'll do that some time in the middle of the week then.

David Carlton
carlton@math.stanford.edu

Re: Pinging Michael C

[David Carlton]

On Mon, 16 Sep 2002 13:11:50 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Mon, Sep 16, 2002 at 10:03:16AM -0700, David Carlton wrote:

>> So would it be okay if I changed the test with all the next's to
>> construct all the objects before examining any of them, updated the
>> comments on the one test to reflect the fact that the bug has been
>> fixed, and then check them in?

> Well, I think Fernando has approved the testsuite-side and I'm fine
> with the C++ of the tests.  I'd say yes.

Committed; revised patches are below.

David Carlton
carlton@math.stanford.edu

2002-09-18  David Carlton  <carlton@math.stanford.edu>

	* gdb.c++/m-static.exp: Remove breakpoints depending on line
	numbers, and replace them by a single breakpoint after the
	constructors are all finished.
	Add test 4.
	* gdb.c++/m-static.cc: Add test 4.
	* gdb.c++/m-static.h: New file.
	* gdb.c++/m-static1.cc: New file.

	* gdb.c++/printmethod.exp: New file.
	* gdb.c++/printmethod.cc: New file.

	* gdb.c++/pr-574.exp: New file.
	* gdb.c++/pr-574.cc: New file.

Index: m-static.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/m-static.cc,v
retrieving revision 1.1
diff -u -p -r1.1 m-static.cc
--- m-static.cc	30 May 2002 19:09:47 -0000	1.1
+++ m-static.cc	18 Sep 2002 18:21:31 -0000
@@ -53,6 +53,10 @@ namespace __gnu_test
 
   template<typename T>
     gnu_obj_2<int> gnu_obj_3<T>::data(etruscan);
+
+  // 2002-08-16
+  // Test four.
+#include "m-static.h"
 } 
 
 // instantiate templates explicitly so their static members will exist
@@ -67,6 +71,7 @@ int main()
   gnu_obj_1		test1(egyptian, 4589);
   gnu_obj_2<long>	test2(roman);
   gnu_obj_3<long>	test3(greek);
+  gnu_obj_4		test4;
 
-  return 0;
+  return 0;				// breakpoint: constructs-done
 }
Index: m-static.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/m-static.exp,v
retrieving revision 1.1
diff -u -p -r1.1 m-static.exp
--- m-static.exp	30 May 2002 19:09:47 -0000	1.1
+++ m-static.exp	18 Sep 2002 18:21:36 -0000
@@ -16,6 +16,7 @@
 
 # Tests for member static data
 # 2002-05-13  Benjamin Kosnik  <bkoz@redhat.com>
+# 2002-08-22  David Carlton <carlton@math.stanford.edu>
 
 # This file is part of the gdb testsuite
 
@@ -33,9 +34,10 @@ set bug_id 0
 
 set testfile "m-static"
 set srcfile ${testfile}.cc
+set srcfile1 ${testfile}1.cc
 set binfile ${objdir}/${subdir}/${testfile}
 
-if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile} ${srcdir}/${subdir}/${srcfile1}" "${binfile}" executable {debug c++}] != "" } {
      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
 }
 
@@ -54,9 +56,13 @@ if ![runto_main] then {
     continue
 }
 
+# First, run to after we've constructed all the objects:
+
+gdb_breakpoint [gdb_get_line_number "constructs-done"]
+gdb_continue_to_breakpoint "end of constructors"
+
+
 # One.
-gdb_test "break 68" "Breakpoint \[0-9\]*.*line 68\\."
-gdb_test "continue" "Continuing\\.\r\n\r\nBreakpoint.*at.*m-static\\.cc:68\r\n.*" "continue to 68"
 
 # simple object, static const bool
 gdb_test "print test1.test" "\\$\[0-9\]* = true" "simple object, static const bool"
@@ -71,8 +77,6 @@ gdb_test "print test1.key2" "\\$\[0-9\]*
 gdb_test "print test1.value" "\\$\[0-9\]* = oriental" "simple object, static enum"
 
 # Two.
-gdb_test "break 69" "Breakpoint \[0-9\]*.*line 69\\."
-gdb_test "continue" "Continuing\\.\r\n\r\nBreakpoint.*at.*m-static\\.cc:69\r\n.*" "continue to 69"
 
 # derived template object, base static const bool
 gdb_test "print test2.test" "\\$\[0-9\]* = true" "derived template object, base static const bool"
@@ -90,8 +94,6 @@ gdb_test "print test2.value" "\\$\[0-9\]
 gdb_test "print test2.value_derived" "\\$\[0-9\].* = etruscan" "derived template object, static enum"
 
 # Three.
-gdb_test "break 71" "Breakpoint \[0-9\]*.*line 71\\."
-gdb_test "continue" "Continuing\\.\r\n\r\nBreakpoint.*at.*m-static\\.cc:71\r\n.*" "continue to 71"
 
 # template object, static derived template data member's base static const bool
 gdb_test "print test3.data.test" "\\$\[0-9\].* = true" "template object, static const bool"
@@ -107,6 +109,20 @@ gdb_test "print test3.data.value" "\\$\[
 
 #  template object, static derived template data member's static enum
 gdb_test "print test3.data.value_derived" "\\$\[0-9\].* = etruscan" "template object, static derived enum"
+
+# 2002-08-16
+# Four.
+
+# static const int initialized in another file.
+gdb_test "print test4.elsewhere" "\\$\[0-9\].* = 221" "static const int initialized elsewhere"
+
+# static const int that nobody initializes.  From PR gdb/635.
+gdb_test "print test4.nowhere" "field nowhere is nonexistent or has been optimised out" "static const int initialized nowhere"
+
+# Perhaps at some point test4 should also include a test for a static
+# const int that was initialized in the header file.  But I'm not sure
+# that GDB's current behavior in such situations is either consistent
+# across platforms or optimal, so I'm not including one now.
 
 gdb_exit
 return 0
--- /dev/null	Thu Apr 11 07:25:15 2002
+++ m-static.h	Fri Aug 16 13:24:37 2002
@@ -0,0 +1,11 @@
+// 2002-08-16
+
+class gnu_obj_4
+{
+ public:
+  static const int elsewhere;
+  static const int nowhere;
+  // At some point, perhaps:
+  // static const int everywhere = 317;
+};
+
--- /dev/null	Thu Apr 11 07:25:15 2002
+++ m-static1.cc	Fri Aug 16 13:11:02 2002
@@ -0,0 +1,9 @@
+// 2002-08-16
+
+namespace __gnu_test {
+#include "m-static.h"
+}
+
+using namespace __gnu_test;
+
+const int gnu_obj_4::elsewhere = 221;
--- /dev/null	Thu Apr 11 07:25:15 2002
+++ pr-574.cc	Wed Sep 18 11:20:17 2002
@@ -0,0 +1,22 @@
+/*
+  An attempt to replicate PR gdb/574 with a shorter program.
+
+  Printing out *theB failed if the program was compiled with GCC 2.95.
+*/
+
+class A {
+public:
+  virtual void foo() {};		// Stick in a virtual function.
+  int a;				// Stick in a data member.
+};
+
+class B : public A {
+  static int b;				// Stick in a static data member.
+};
+
+int main()
+{
+  B *theB = new B;
+
+  return 0;				// breakpoint: constructs-done
+}
--- /dev/null	Thu Apr 11 07:25:15 2002
+++ pr-574.exp	Wed Sep 18 11:19:55 2002
@@ -0,0 +1,72 @@
+# Copyright 2002 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Tests for the bug mentioned in PR gdb/574.  It's a bit
+# idiosyncratic, so I gave it its own file.
+
+# 2002-08-16  David Carlton <carlton@math.stanford.edu>
+
+# This file is part of the gdb testsuite
+
+if $tracelevel then {
+        strace $tracelevel
+        }
+
+if { [skip_cplus_tests] } { continue }
+
+#
+# test running programs
+#
+set prms_id 0
+set bug_id 0
+
+set testfile "pr-574"
+set srcfile ${testfile}.cc
+set binfile ${objdir}/${subdir}/${testfile}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if [get_compiler_info ${binfile} "c++"] {
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+
+if ![runto_main] then {
+    perror "couldn't run to breakpoint"
+    continue
+}
+
+# First, run to after we've constructed the object:
+
+gdb_breakpoint [gdb_get_line_number "constructs-done"]
+gdb_continue_to_breakpoint "end of constructors"
+
+# This failed, as long as the code was compiled with GCC v. 2.
+
+# Different compilers order the data for <A> differently, so I'm not
+# matching the result exactly.
+
+gdb_test "print *theB" "\\$\[0-9\]* = {<A> = {\[^}\]*}, static b = <optimized out>}" "PR gdb/574"
+
+gdb_exit
+return 0
--- /dev/null	Thu Apr 11 07:25:15 2002
+++ printmethod.cc	Wed Sep 18 11:18:41 2002
@@ -0,0 +1,14 @@
+/* Create some objects, and try to print out their methods.  */
+
+class A {
+public:
+  virtual void virt() {};
+  void nonvirt() {};
+};
+
+int main()
+{
+  A *theA = new A;
+
+  return 0;				// breakpoint: constructs-done
+}
--- /dev/null	Thu Apr 11 07:25:15 2002
+++ printmethod.exp	Wed Sep 18 11:18:24 2002
@@ -0,0 +1,69 @@
+# Copyright 2002 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# This tries to print out methods of classes.
+
+# 2002-08-16  David Carlton <carlton@math.stanford.edu>
+
+# This file is part of the gdb testsuite
+
+if $tracelevel then {
+        strace $tracelevel
+        }
+
+if { [skip_cplus_tests] } { continue }
+
+#
+# test running programs
+#
+set prms_id 0
+set bug_id 0
+
+set testfile "printmethod"
+set srcfile ${testfile}.cc
+set binfile ${objdir}/${subdir}/${testfile}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if [get_compiler_info ${binfile} "c++"] {
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+
+if ![runto_main] then {
+    perror "couldn't run to breakpoint"
+    continue
+}
+
+# First, run to after we've constructed the object:
+
+gdb_breakpoint [gdb_get_line_number "constructs-done"]
+gdb_continue_to_breakpoint "end of constructors"
+
+# The first of these is for PR gdb/653.
+
+gdb_test "print theA->virt" "\\$\[0-9\]* = &A::virt\\(\\)" "print virtual method."
+gdb_test "print theA->nonvirt" "Cannot take address of a method" "print nonvirtual method."
+
+gdb_exit
+return 0

Re: Pinging Michael C

[Andrew Cagney]

>> I don't think we want to add tests to make gdb dump core to the 
>> testsuite right away.  It should go in as soon as someone fixes the 
>> problem to prevent a regression.  Alternatively we can add it in and 
>> explicitly skip the test with a explicit call to the kfail proc...
> 
> 
> Fortunately, David has since fixed the bug.  I think this patch is
> ready to go in, once we agree on ChangeLog formatting.
> 
> 
>> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00469.html
>> >
> 
>> 
>> I was talking to Andrew about collecting these regression tests into a 
>> single file (someone would eventually move them into one of the other 
>> files if the test can be associated with some feature).
>> 
>> Andrew, what was the name of the file? I forgot...
> 
> 
> I have an even better idea (I think :).  I'll post an RFC for it in a
> second.

Fernando and I were discussing the idea of:

gdb.base/gdb-bugs.exp (gdb.base/base-bugs.exp?)
gdb.mi/mi-bugs.exp

(just waiting :-)

Andrew