From: Pedro Alves <palves@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: [pushed] PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - another test
Date: Tue, 03 Jun 2014 11:53:00 -0000 [thread overview]
Message-ID: <538DB728.7080702@redhat.com> (raw)
In-Reply-To: <538D85A9.5010004@redhat.com>
On 06/03/2014 09:22 AM, Pedro Alves wrote:
> On 06/03/2014 12:16 AM, Pedro Alves wrote:
>
>> Let me know what you think, and feel free to push if it
>> looks OK. Tested on all combinations of
>> native|gdbserver X hardware-|software- stepping. At least,
>> I think I did. If not this exact version, some other minor
>> variation. :-)
>
> Bah, I woke up realizing that the version I posted forgets to
> clone the shadow buffer! Let me fix that and repost...
>
I managed to come up with a test that exposed this. Basically, it does:
(gdb) disassemble test
Dump of assembler code for function test:
0x0000000000400766 <+0>: push %rbp
0x0000000000400767 <+1>: mov %rsp,%rbp
=> 0x000000000040076a <+4>: nop
0x000000000040076b <+5>: nop
0x000000000040076c <+6>: pop %rbp
0x000000000040076d <+7>: retq
End of assembler dump.
(gdb) si&
(gdb) del $bpnum
(gdb) disassemble test
Dump of assembler code for function test:
0x0000000000400766 <+0>: push %rbp
0x0000000000400767 <+1>: mov %rsp,%rbp
0x000000000040076a <+4>: nop
=> 0x000000000040076b <+5>: int3
0x000000000040076c <+6>: pop %rbp
0x000000000040076d <+7>: retq
End of assembler dump.
And note the bogus "int3" in the second disassemble output.
The test actually fails in a different way currently against
gdbserver:
(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.
8<--------------
PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - test
GDB gets confused when removing a software single-step breakpoint that
is at the same address as another breakpoint. Add another kfailed
test.
gdb/testsuite/
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.
---
gdb/testsuite/ChangeLog | 6 ++
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c | 29 +++++++
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp | 109 +++++++++++++++++++++++++
3 files changed, 144 insertions(+)
create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c
create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 9ded6eb..644f5ac 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+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.
+
2014-06-02 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-parameter.exp: New file.
diff --git a/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c b/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c
new file mode 100644
index 0000000..c3c26fe
--- /dev/null
+++ b/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c
@@ -0,0 +1,29 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2014 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 3 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, see <http://www.gnu.org/licenses/>. */
+
+static void
+test (void)
+{
+ label: asm (" nop"); label2: asm (" nop"); /* must be a single line */
+}
+
+int
+main (void)
+{
+ test ();
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp b/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
new file mode 100644
index 0000000..a129bb7
--- /dev/null
+++ b/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
@@ -0,0 +1,109 @@
+# Copyright (C) 2014 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 3 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, see <http://www.gnu.org/licenses/>.
+
+# Test that GDB doesn't get confused in the following scenario
+# (PR breakpoints/17000). Say, we have this program:
+#
+# => 0xff000001 INSN1
+# 0xff000002 INSN2
+#
+# The PC currently points at INSN1.
+#
+# 1 - User sets a breakpoint at 0xff000002 (INSN2).
+#
+# 2 - User steps. On software single-step archs, this sets a software
+# single-step breakpoint at 0xff000002 (INSN2) too.
+#
+# 3 - User deletes breakpoint (INSN2) before the single-step finishes.
+#
+# 4 - The single-step finishes, and GDB removes the single-step
+# breakpoint.
+
+standard_testfile
+
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile debug]} {
+ return -1
+}
+
+if ![runto_main] {
+ fail "Can't run to main"
+ return 0
+}
+
+set line_re "\[^\r\n\]*"
+
+gdb_test "b test:label" "Breakpoint .*"
+gdb_continue_to_breakpoint "run past setup"
+delete_breakpoints
+
+# So we can precisely control breakpoint insertion order.
+gdb_test_no_output "set breakpoint always-inserted on"
+
+# Capture disassembly output. PREFIX is used as test prefix. The
+# current instruction indicator (=>) is stripped away.
+proc disassemble { prefix } {
+ with_test_prefix "$prefix" {
+ set output [capture_command_output "disassemble test" ""]
+ return [string map {"=>" " "} $output]
+ }
+}
+
+# Issue a stepi and immediately delete the user breakpoint that is set
+# at the same address as the software single-step breakpoint. Do this
+# in a user defined command, so that the stepi's trap doesn't have a
+# chance to be handled before further input is processed. We then
+# compare before/after disassembly. GDB should be able to handle
+# deleting the user breakpoint before deleting the single-step
+# breakpoint. E.g., we shouldn't see breakpoint instructions in the
+# disassembly.
+
+set disasm_before [disassemble "before"]
+
+gdb_test "b test:label2" ".*" "set breakpoint where si will land"
+
+set test "define stepi_del_break"
+gdb_test_multiple $test $test {
+ -re "Type commands for definition of \"stepi_del_break\".\r\nEnd with a line saying just \"end\".\r\n>$" {
+ gdb_test "si&\ndel \$bpnum\nend" "" $test
+ }
+}
+
+set command "stepi_del_break"
+set test $command
+setup_kfail "breakpoints/17000" "*-*-*"
+gdb_test_multiple $command $test {
+ -re "^$command\r\n$gdb_prompt " {
+ # Note no end anchor, because "si&" finishes and prints the
+ # current frame/line after the prompt is printed.
+ pass $test
+ }
+}
+
+# Now consume the output of the finished "si&".
+set test "si& finished"
+gdb_test_multiple "" $test {
+ -re "must be a single line \\\*/\r\n" {
+ pass $test
+ }
+}
+
+set disasm_after [disassemble "after"]
+
+set test "before/after disassembly matches"
+if ![string compare $disasm_before $disasm_after] {
+ pass $test
+} else {
+ fail $test
+}
--
1.9.0
next prev parent reply other threads:[~2014-06-03 11:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-29 20:11 [RFA/7.8] user breakpoint not inserted if software-single-step at same location Joel Brobecker
2014-05-29 23:17 ` Pedro Alves
2014-05-30 12:22 ` Joel Brobecker
2014-05-30 12:51 ` Pedro Alves
2014-05-30 13:27 ` Joel Brobecker
2014-05-30 15:57 ` Pedro Alves
2014-05-30 16:19 ` Joel Brobecker
2014-05-30 16:23 ` Pedro Alves
2014-05-30 16:23 ` Pedro Alves
2014-06-03 11:55 ` Yao Qi
2014-06-03 12:00 ` Pedro Alves
2014-06-03 12:12 ` Andreas Schwab
2014-06-03 12:19 ` Pedro Alves
2014-06-04 5:14 ` Yao Qi
2014-06-04 8:01 ` Pedro Alves
2014-06-04 12:58 ` Yao Qi
2014-05-30 19:35 ` Joel Brobecker
2014-06-02 23:16 ` Pedro Alves
2014-06-03 8:22 ` Pedro Alves
2014-06-03 11:53 ` Pedro Alves [this message]
2014-06-03 13:08 ` [pushed] PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - another test Pedro Alves
2014-06-06 19:05 ` [pushed] sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux. (was: [pushed] PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - another test) Pedro Alves
2014-06-09 14:26 ` [pushed] sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux Pedro Alves
2014-06-03 13:11 ` [RFA/7.8] user breakpoint not inserted if software-single-step at same location Pedro Alves
2014-06-03 13:35 ` Joel Brobecker
2014-06-03 15:41 ` Pedro Alves
2014-06-03 16:23 ` Joel Brobecker
2014-06-03 16:51 ` Pedro Alves
2014-06-03 17:27 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=538DB728.7080702@redhat.com \
--to=palves@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox