[pushed] PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - another test
Commit Message
On 06/03/2014 12:53 PM, Pedro Alves wrote:
> (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
> stepi_del_break
> Cannot execute this command while the target is running.
> (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: stepi_del_break
>
> The error is because GDB tried to remove the breakpoint from
> memory while the thread was running, and we can't talk to the
> server in the all-stop RSP until we get a stop reply, but in any
> case, GDB shouldn't even be attempting to remove the breakpoint,
> exactly because there was a sss breakpoint at the same address.
>
> I've added a kfail, and pushed it.
Gosh, so many different mode combinations... So the fix for
PR17000 doesn't fix that failure when testing against gdbserver
_and_ hardware stepping. Well, of course it doesn't, because in
that case GDB will really try to remove the breakpoint, because
there's no overlapping software single-step breakpoint.
I've pushed this to detect the scenario and skip the test.
8<---------------------
Subject: [PATCH] Skip sss-bp-on-user-bp-2.exp on remote hardware step targets.
gdb/testsuite/
2014-06-03 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Skip if testing with a remote
target that doesn't use software single-stepping.
---
gdb/testsuite/ChangeLog | 5 ++++
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp | 39 ++++++++++++++++++++++++++
2 files changed, 44 insertions(+)
@@ -1,5 +1,10 @@
2014-06-03 Pedro Alves <palves@redhat.com>
+ * gdb.base/sss-bp-on-user-bp-2.exp: Skip if testing with a remote
+ target that doesn't use software single-stepping.
+
+2014-06-03 Pedro Alves <palves@redhat.com>
+
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp-2.c: New file.
* gdb.base/sss-bp-on-user-bp-2.exp: New file.
@@ -42,6 +42,45 @@ if ![runto_main] {
return 0
}
+delete_breakpoints
+
+# With the all-stop RSP, we can't talk to the target while it's
+# running, until we get back the stop reply. If not using single-step
+# breakpoints, then the "del" in stepi_del_break below will try to
+# delete the user breakpoint from the target, which will fail, with
+# "Cannot execute this command while the target is running.". On
+# software single-step targets, that del shouldn't trigger any RSP
+# traffic. Just skip the test if testing against a remove target and
+# not using software single-stepping. IOW, skip the test if we see a
+# 'vCont;s' or 's' in the RSP traffic.
+
+gdb_test_no_output "set debug remote 1"
+
+set rsp_hardware_step 0
+
+# Probe for software single-step breakpoint use.
+set test "probe RSP hardware step"
+gdb_test_multiple "si" $test {
+ -re "\\\$vCont;s.*$gdb_prompt $" {
+ set rsp_hardware_step 1
+ pass $test
+ }
+ -re "\\\$s#.*$gdb_prompt $" {
+ set rsp_hardware_step 1
+ pass $test
+ }
+ -re "$gdb_prompt $" {
+ pass $test
+ }
+}
+
+if { $rsp_hardware_step } {
+ unsupported "remote target doesn't use software single-stepping"
+ return
+}
+
+gdb_test_no_output "set debug remote 0"
+
set line_re "\[^\r\n\]*"
gdb_test "b test:label" "Breakpoint .*"