[RFA/c++testsuite] New test for constructor breakpoints

[RFA/c++testsuite] New test for constructor breakpoints

[Daniel Jacobowitz]

We've got a PR that breakpoints on constructors/destructors do not work in
g++ v3 mode.  I've identified the problems:

  - Multiple symbols with the same demangled name.  We can work around this
   for stabs, because we have the physname.  We don't have that option for
   DWARF-2, and we shouldn't need to for stabs.  I have a patch for the
   workaround.  We get the [not-in-charge] constructor by default,
   unfortunately.

  - stabs does not specify the class name in the debug info for the
   constructor.  Work around it using physnames again.

  - DWARF-2 we're just getting the wrong functions.  I haven't tracked this
   down yet.

This patch passes on g++ v2, fails on g++ v3 without the two patches I'm
about to post, and fails on v3 dwarf-2 period.  I'll look in to that.

OK to commit the tests anyway?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-02-14  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.c++/ovldbreak.exp: Test breakpoints on the constructors.

Index: testsuite/gdb.c++/ovldbreak.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ovldbreak.exp,v
retrieving revision 1.3
diff -u -r1.3 ovldbreak.exp
--- ovldbreak.exp	2001/01/28 23:49:43	1.3
+++ ovldbreak.exp	2002/02/14 23:17:55
@@ -231,8 +231,6 @@
 \[0-9\]+\[\t \]+breakpoint     keep y\[\t \]+$hex in foo::overload1arg\\((void|)\\) at.*$srcfile:110" \
     "breakpoint info (after cancel)"
 
-
-
 # Delete these breakpoints.
 
 send_gdb "delete breakpoints\n"
@@ -309,8 +307,36 @@
     "breakpoint info (after setting on all)"
 
 
+# Set breakpoints on the overloaded constructor.
+set menu_constructor "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::foo\\(foo ?&\\) at.*$srcfile:104\r\n\\\[3\\\] foo::foo\\(int, char const ?\\*\\) at.*$srcfile:103\r\n\\\[4\\\] foo::foo\\(int\\) at.*$srcfile:102\r\n> $"
 
+set_bp_overloaded "foo::foo" "$menu_constructor"	2	26	104
+set_bp_overloaded "foo::foo" "$menu_constructor"	3	27	103
+set_bp_overloaded "foo::foo" "$menu_constructor"	4	28	102
+
 # Run through each breakpoint.
+
+proc continue_to_bp_constructor {bpnumber argtypes args actuals} {
+    global gdb_prompt hex decimal srcfile 
+
+    send_gdb "continue\n"
+    gdb_expect {
+	-re "Continuing.\r\n\r\nBreakpoint ${bpnumber}, (${hex} in )?foo::foo(\\(${argtypes}\\))? \\(this=${hex}(, )?${actuals}\\) at.*${srcfile}:${decimal}\r\n${decimal}\[\t \]+foo::foo  *\\(${args}\\).*\r\n.*$gdb_prompt $" {
+	    pass "continue to bp overloaded constructor : ${argtypes}"
+	}
+        -re ".*$gdb_prompt $" {
+	    fail "continue to bp overloaded constructor : ${argtypes}" 
+	}
+        timeout {
+	    fail "continue to bp overloaded constructor : ${argtypes} (timeout)"
+	}
+    }
+}
+
+continue_to_bp_constructor 28 "int" "int i" "i=111"
+continue_to_bp_constructor 27 "int, char const ?\\*" \
+	"int i, const char \\*ccp" "i=222, ccp=$hex \"A\""
+continue_to_bp_constructor 26 "foo ?&" "foo& afoo" "afoo=@$hex"
 
 proc continue_to_bp_overloaded {bpnumber argtype actuals} {
     global gdb_prompt hex decimal srcfile 

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Michael Elizabeth Chastain]

This patch is declined for now, because I believe there is still controversy
about the right thing to do for overloaded constructors and destructors.

(And I am a party to that controversy ... so someone admonish please me if
I start getting thickheaded).

Michael C

===

2002-02-14  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.c++/ovldbreak.exp: Test breakpoints on the constructors.

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Daniel Jacobowitz]

On Fri, Feb 15, 2002 at 06:50:05PM -0600, Michael Elizabeth Chastain wrote:
> This patch is declined for now, because I believe there is still controversy
> about the right thing to do for overloaded constructors and destructors.
> 
> (And I am a party to that controversy ... so someone admonish please me if
> I start getting thickheaded).

Let me clarify terminology, please.

The patch tests _overloaded_ constructors.  The bug, however, is with
_cloned_ constructors.  Not the same thing at all.  Cloned constructors
are not user-visible objects; they only differ in that they use
different offsets into the object based on whether it is a baseclass or
the principal object.

The test should definitely pass as-written, in my opinion, possibly
with a few additional words added to the output but not with more menu
choices.  This is an implementation detail that we may want to show to
users but we should avoid requiring their knowledge of it at all
possible.

> 
> Michael C
> 
> ===
> 
> 2002-02-14  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* gdb.c++/ovldbreak.exp: Test breakpoints on the constructors.
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Michael Elizabeth Chastain]

Hi Daniel,

> The patch tests _overloaded_ constructors.

Ah, you are right.  I saw the choice menu and jumped to an incorrect
conclusion about what you were doing.  I'll revisit the patch.

> The bug, however, is with
> _cloned_ constructors.  Not the same thing at all.  Cloned constructors
> are not user-visible objects; they only differ in that they use
> different offsets into the object based on whether it is a baseclass or
> the principal object.

But the cloned constructor is visible.  For instance, suppose Foo is
a virtual base class, and suppose Foo::Foo calls other functions,
and suppose that I set a breakpoint on another function.  Then the
not-in-charge version of Foo::Foo is on the stack and it is going to
appear to the user with *some* name.

I would like to show this as Foo::Foo$nic, and I would like the user to
be able to set breakpoints on either Foo::Foo or Foo::Foo$nic or both,
as they see fit.

Michael C

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Michael Elizabeth Chastain]

This patch is returned for rework.  I like the patch, but there is
a cascade problem:

  "set_bp_overloaded foo::foo" tests FAIL
  the breakpoints are not present
  continue_to_bp_constructor issues "continue" unconditionally
  the script loses synchronization with the program-under-test at this point
  all the tests after that FAIL

This happens on target=native host=i686-pc-linux-gnu with all the gcc v3
configurations:

  gcc 3.0.3, -gdwarf-2
  gcc 3.0.3, -gstabs+
  gcc 3.0.4-20020215, -gdwarf-2
  gcc 3.0.4-20020215, -gstabs+
  gcc gcc-3_0-branch, -gdwarf-2
  gcc gcc-3_0-branch, -gstabs+
  gcc HEAD, -gdwarf-2
  gcc HEAD, -gstabs+

Can you do something in continue_to_bp_constructor to keep synchronization?
Maybe:

  send_gdb "info b ${bpnumber}\n"
  gdb_expect {
    -re "Num.*\r\n${bpnumber}.*\r\n.*$gdb_prompt $" {
      send_gdb "continue\n"
      gdb_expect {
	...
      }
    }
    -re "No breakpoint or watchpoint number ${bpnumber}.*gdb_prompt $" {
      fail "continue to bp overloaded constructor : ${argtypes}"
    }
    -re ".*$gdb_prompt $" {
      fail "continue to bp overloaded constructor : ${argtypes}"
    }
    timeout {
      fail "continue to bp overloaded constructor : ${argtypes} (timeout)"
    }
  }

Or if you have a better idea, go for it.  I just want to fix the problem
where all the currently-working tests FAIL if the new tests FAIL.

Michael C

===

2002-02-14  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.c++/ovldbreak.exp: Test breakpoints on the constructors.

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Daniel Jacobowitz]

On Mon, Feb 18, 2002 at 02:25:51PM -0600, Michael Elizabeth Chastain wrote:
> This patch is returned for rework.  I like the patch, but there is
> a cascade problem:
> 
>   "set_bp_overloaded foo::foo" tests FAIL
>   the breakpoints are not present
>   continue_to_bp_constructor issues "continue" unconditionally
>   the script loses synchronization with the program-under-test at this point
>   all the tests after that FAIL
> 
> This happens on target=native host=i686-pc-linux-gnu with all the gcc v3
> configurations:

This is all over the GDB testsuite.  It's a tremendously complicated
problem :)

> Can you do something in continue_to_bp_constructor to keep synchronization?
> Maybe:
> 
>   send_gdb "info b ${bpnumber}\n"
>   gdb_expect {
>     -re "Num.*\r\n${bpnumber}.*\r\n.*$gdb_prompt $" {
>       send_gdb "continue\n"
>       gdb_expect {
> 	...
>       }
>     }
>     -re "No breakpoint or watchpoint number ${bpnumber}.*gdb_prompt $" {
>       fail "continue to bp overloaded constructor : ${argtypes}"
>     }
>     -re ".*$gdb_prompt $" {
>       fail "continue to bp overloaded constructor : ${argtypes}"
>     }
>     timeout {
>       fail "continue to bp overloaded constructor : ${argtypes} (timeout)"
>     }
>   }
> 
> Or if you have a better idea, go for it.  I just want to fix the problem
> where all the currently-working tests FAIL if the new tests FAIL.

I don't think that would work... let me think about it tonight.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Daniel Jacobowitz]

On Mon, Feb 18, 2002 at 02:25:51PM -0600, Michael Elizabeth Chastain wrote:
> This patch is returned for rework.  I like the patch, but there is
> a cascade problem:
> 
>   "set_bp_overloaded foo::foo" tests FAIL
>   the breakpoints are not present
>   continue_to_bp_constructor issues "continue" unconditionally
>   the script loses synchronization with the program-under-test at this point
>   all the tests after that FAIL

Well, I had to file a bug on expect's manual page to get this to work,
but I did.  How's this patch?  The magic is in -notransfer.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-02-19  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.c++/ovldbreak.exp: Test breakpoints on the constructors.

Index: ovldbreak.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ovldbreak.exp,v
retrieving revision 1.3
diff -u -r1.3 ovldbreak.exp
--- ovldbreak.exp	2001/01/28 23:49:43	1.3
+++ ovldbreak.exp	2002/02/19 23:32:27
@@ -231,8 +231,6 @@
 \[0-9\]+\[\t \]+breakpoint     keep y\[\t \]+$hex in foo::overload1arg\\((void|)\\) at.*$srcfile:110" \
     "breakpoint info (after cancel)"
 
-
-
 # Delete these breakpoints.
 
 send_gdb "delete breakpoints\n"
@@ -309,13 +307,58 @@
     "breakpoint info (after setting on all)"
 
 
+# Set breakpoints on the overloaded constructor.
+set menu_constructor "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::foo\\(foo ?&\\) at.*$srcfile:104\r\n\\\[3\\\] foo::foo\\(int, char const ?\\*\\) at.*$srcfile:103\r\n\\\[4\\\] foo::foo\\(int\\) at.*$srcfile:102\r\n> $"
 
+set_bp_overloaded "foo::foo" "$menu_constructor"	2	26	104
+set_bp_overloaded "foo::foo" "$menu_constructor"	3	27	103
+set_bp_overloaded "foo::foo" "$menu_constructor"	4	28	102
+
 # Run through each breakpoint.
 
-proc continue_to_bp_overloaded {bpnumber argtype actuals} {
+global last_bp_hit
+set last_bp_hit 300
+
+proc continue_to_bp_constructor {bpnumber argtypes args actuals} {
     global gdb_prompt hex decimal srcfile 
+    global last_bp_hit
+
+    if {$last_bp_hit < 26} {
+	fail "continue to bp overloaded constructor : ${argtypes} (overshot)"
+	return
+    }
 
     send_gdb "continue\n"
+    gdb_expect {
+	-re "Continuing.\r\n\r\nBreakpoint ${bpnumber}, (${hex} in )?foo::foo(\\(${argtypes}\\))? \\(this=${hex}(, )?${actuals}\\) at.*${srcfile}:${decimal}\r\n${decimal}\[\t \]+foo::foo  *\\(${args}\\).*\r\n.*$gdb_prompt $" {
+	    pass "continue to bp overloaded constructor : ${argtypes}"
+	}
+	-notransfer -re "Continuing.\r\n\r\nBreakpoint (\[0-9\]*).*$gdb_prompt $" {
+	    set last_bp_hit $expect_out(1,string)
+	    fail "continue to bp overloaded constructor : ${argtypes} (wrong breakpoint)"
+	}
+        -re ".*$gdb_prompt $" {
+	    fail "continue to bp overloaded constructor : ${argtypes}" 
+	}
+        timeout {
+	    fail "continue to bp overloaded constructor : ${argtypes} (timeout)"
+	}
+    }
+}
+
+continue_to_bp_constructor 28 "int" "int i" "i=111"
+continue_to_bp_constructor 27 "int, char const ?\\*" \
+	"int i, const char \\*ccp" "i=222, ccp=$hex \"A\""
+continue_to_bp_constructor 26 "foo ?&" "foo& afoo" "afoo=@$hex"
+
+proc continue_to_bp_overloaded {bpnumber argtype actuals} {
+    global gdb_prompt hex decimal srcfile
+    global last_bp_hit
+
+    if { $last_bp_hit != $bpnumber } {
+	send_gdb "continue\n"
+    }
+
     gdb_expect {
 	-re "Continuing.\r\n\r\nBreakpoint ${bpnumber}, (${hex} in )?foo::overload1arg(\\(${argtype}\\))? \\(this=${hex}(, )?${actuals}\\) at.*${srcfile}:${decimal}\r\n${decimal}\[\t \]+int foo::overload1arg \\(${argtype}( arg)?\\).*\r\n.*$gdb_prompt $" {
 	    pass "continue to bp overloaded : ${argtype}"

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Michael Elizabeth Chastain]

Aieee, I am having an instant allergic reaction to -notransfer.  Nothing
else in the test suite uses it except for some internal multi-line stuff
in gdb_test which I do not trust at all.  So we get to be the first
soldier on the beach.  I don't want to have result variations depending
on what version of "expect" somebody has.

There's got to be a better way of tracking which breakpoints have
been successfully set.  Maybe set_bp_overloaded should record that
information?

Michael C

Re: [RFA/c++testsuite] New test for constructor breakpoints

[Daniel Jacobowitz]

On Tue, Feb 19, 2002 at 06:03:59PM -0600, Michael Elizabeth Chastain wrote:
> Aieee, I am having an instant allergic reaction to -notransfer.  Nothing
> else in the test suite uses it except for some internal multi-line stuff
> in gdb_test which I do not trust at all.  So we get to be the first
> soldier on the beach.  I don't want to have result variations depending
> on what version of "expect" somebody has.
> 
> There's got to be a better way of tracking which breakpoints have
> been successfully set.  Maybe set_bp_overloaded should record that
> information?

It has been in expect since at least 1995.  I'd much prefer not to have
an allergic reaction to it; in fact I'd much prefer to use it more
universally, to reduce similar cascades.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer