Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: Pedro Alves <palves@redhat.com>, Andreas Schwab <schwab@suse.de>
Cc: Joel Brobecker <brobecker@adacore.com>, <gdb-patches@sourceware.org>
Subject: Re: [RFA/7.8] user breakpoint not inserted if software-single-step at same location
Date: Wed, 04 Jun 2014 05:14:00 -0000	[thread overview]
Message-ID: <538EAACD.8000700@codesourcery.com> (raw)
In-Reply-To: <538DBD65.5050409@redhat.com>

On 06/03/2014 08:19 PM, Pedro Alves wrote:
> On 06/03/2014 01:12 PM, Andreas Schwab wrote:
>> Pedro Alves <palves@redhat.com> writes:
>>
>>> Ah, thanks.  We need to replace then with asm("nop") then.
>>
>> nop isn't portable.
> 
> Yes, but it doesn't matter what the instruction is as
> long as it's a single instruction that doesn't do much.
> For archs that don't have "nop" (like e.g., IA64), we can
> just use #ifdef to pick another insn.
> 

Pedro, here is the patch to tweak sss-bp-on-user-bp.exp.
I give up on looking for a portable "nop" for various arch.  In
stead, we can use disassemble to get the next instruction address
and set breakpoint there.  See details in the commit log below.

-- 
Yao (齐尧)

Subject: [PATCH] Tweak sss-bp-on-user-bp.exp

sss-bp-on-user-bp.c has an assumption that write to integer can be
compiled to a single instruction, which isn't true on some arch, such
as arm.  This test requires setting two breakpoints on two consecutive
instructions, so this patch is to get the address of the next
instruction via disassemble and set the 2nd breakpoint there.  This
approach is portable.

This patch fixes the fails in sss-bp-on-user-bp.exp on arm-none-abi
target.  There is no change in x86 test results.  I also revert the
patch to PR breakpoints/17000, and verified that the patched
sss-bp-on-user-bp.exp still triggers the fail on
x86-with-software-single-step.

gdb/testsuite:

2014-06-04  Yao Qi  <yao@codesourcery.com>

	* gdb.base/sss-bp-on-user-bp.c (main): Remove comments.
	* gdb.base/sss-bp-on-user-bp.exp: Don't set breakpoint on
	"set bar break here".  Get the next instruction address and
	set breakpoint there.  Remove "bar break" from the regexp
	patterns.
---
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.c   |  4 ++--
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp | 20 +++++++++++++++++---
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/sss-bp-on-user-bp.c b/gdb/testsuite/gdb.base/sss-bp-on-user-bp.c
index ff82051..edc2e8c 100644
--- a/gdb/testsuite/gdb.base/sss-bp-on-user-bp.c
+++ b/gdb/testsuite/gdb.base/sss-bp-on-user-bp.c
@@ -21,10 +21,10 @@
 int
 main (void)
 {
-  /* Assume writes to integers compile to a single instruction.  */
   volatile int i = 0;
 
   i = 1;     /* set foo break here */
-  i = 2;     /* set bar break here */
+  i = 2;
+
   return 0;
 }
diff --git a/gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp b/gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp
index 2a12ad6..0b39fc1 100644
--- a/gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp
+++ b/gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp
@@ -32,7 +32,21 @@ if ![runto_main] then {
 gdb_breakpoint [gdb_get_line_number "set foo break here"]
 gdb_continue_to_breakpoint "first breakpoint" ".* set foo break here .*"
 
-gdb_breakpoint [gdb_get_line_number "set bar break here"]
+# Get the address of the next instruction and set a breakpoint there.
+set next_insn_addr ""
+set test "disassemble main"
+gdb_test_multiple $test $test {
+    -re ".*=> $hex <\\+$decimal>:\[^\r\n\]+\r\n   ($hex) .*$gdb_prompt $" {
+	set next_insn_addr $expect_out(1,string)
+	pass $test
+    }
+}
+
+if { $next_insn_addr == "" } {
+    return -1
+}
+
+gdb_test "b *$next_insn_addr" "Breakpoint .*"
 
 # So that GDB doesn't try to remove the regular breakpoint when the
 # step finishes.
@@ -43,9 +57,9 @@ gdb_test_no_output "set breakpoint always-inserted on"
 # remove it.  But, a regular breakpoint is planted there already, and
 # with always-inserted on, should remain planted when the step
 # finishes.
-gdb_test "si" "Breakpoint .* bar break .*"
+gdb_test "si" "Breakpoint .*"
 
 # If the breakpoint is still correctly inserted, then this jump should
 # re-trigger it.  Otherwise, GDB will lose control and the program
 # will exit.  See PR breakpoints/17000.
-gdb_test "jump *\$pc" "Breakpoint .* bar break .*"
+gdb_test "jump *\$pc" "Breakpoint .*"
-- 
1.9.0


  reply	other threads:[~2014-06-04  5:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-29 20:11 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 [this message]
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               ` [pushed] PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - another test Pedro Alves
2014-06-03 13:08                 ` 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=538EAACD.8000700@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=schwab@suse.de \
    /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