Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org, gdb-patches@sourceware.org
Subject: Re: single-step breakpoints
Date: Sun, 30 Apr 2006 03:20:00 -0000	[thread overview]
Message-ID: <200604292314.k3TNE3uH012648@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <200604252154.k3PLscQe005675@elgar.sibelius.xs4all.nl> (message 	from Mark Kettenis on Tue, 25 Apr 2006 23:54:38 +0200 (CEST))

> Date: Tue, 25 Apr 2006 23:54:38 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> 
> > Date: Tue, 25 Apr 2006 17:02:00 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > On Tue, Apr 25, 2006 at 10:39:36PM +0200, Mark Kettenis wrote:
> > > Hi Daniel,
> > > 
> > > There a slight problem with insert_single_step_breakpoint() and
> > > remove_single_step_breakpoints().  On OpenBSD, inserting a breakpoint
> > > into the kernel-provided signal trampoline, may fail.  Unfortunately,
> > > the caller of insert_single_step_breakpoint() never notices this, and
> > > calls remove_single_step_breakpoints() to remove the breakpoints.
> > > Unfortunately that makes us hit the gdb_assert() in there.
> > > 
> > > This patch makes us avoid this while still making an attempt to catch
> > > misuse of the interface.
> > 
> > Hmm - this is also true on some GNU/Linux targets, although none that
> > use software single step (yet - though I think I know how to trigger it
> > on ARM, some kernel fixes would also be needed).
> > 
> > My question is, is there something more useful we could be doing? 
> > If the single step breakpoint fails, then continuing will make us lose
> > control.  Maybe it should be an error().
> 
> That may not be such a bad idea.  But we'll need to adjust
> gdb.base/sigbpt.exp since it will end up in an infinite loop trying to
> step the target.
> 
> I'll look a bit more into it later this week.  Need to get some sleep now.

Yes, erroring out is defenitely a better approach than warn and have
things run away.  Here's a patch and some adjustments to the testsuite
to prevent the tests from going into an infinite loop.

ok?


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* breakpoint.c (insert_single_step_breakpoint): Make a failure to
	insert a single-step breakpoint an error instead of a warning.

	* breakpoint.c (remove_single_step_breakpoints): Bail out early if
	no breakpoints are inserted.

Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.225
diff -u -p -r1.225 breakpoint.c
--- breakpoint.c 18 Apr 2006 19:20:06 -0000 1.225
+++ breakpoint.c 29 Apr 2006 23:11:12 -0000
@@ -7717,7 +7717,7 @@ insert_single_step_breakpoint (CORE_ADDR
 
   *bpt_p = deprecated_insert_raw_breakpoint (next_pc);
   if (*bpt_p == NULL)
-    warning (_("Could not insert single-step breakpoint at 0x%s"),
+    error (_("Could not insert single-step breakpoint at 0x%s"),
 	     paddr_nz (next_pc));
 }
 
Index: testsuite/ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* gdb.base/sigbpt.exp (stepi_out): FAIL when inserting a
	single-step breakpoint fails; make this a KFAIL on
	sparc*-*-openbsd*.
	* gdb.base/siginfo.exp: Likewise.
	* gdb.base/sigstep.exp (advance, advancei): Likewise.

Index: testsuite/gdb.base/sigbpt.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/sigbpt.exp,v
retrieving revision 1.5
diff -u -p -r1.5 sigbpt.exp
--- testsuite/gdb.base/sigbpt.exp 27 Apr 2005 16:35:14 -0000 1.5
+++ testsuite/gdb.base/sigbpt.exp 29 Apr 2006 23:11:21 -0000
@@ -166,6 +166,10 @@ proc stepi_out { name args } {
     # trampoline, and back to the instruction that faulted.
     set test "${name}; stepi out of handler"
     gdb_test_multiple "stepi" "$test" {
+	-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
+	    setup_kfail "sparc*-*-openbsd*" gdb/1736
+	    fail "$test (could not insert single-step breakpoint)"
+	}
 	-re "keeper.*$gdb_prompt $" {
 	    send_gdb "stepi\n"
 	    exp_continue
Index: testsuite/gdb.base/siginfo.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/siginfo.exp,v
retrieving revision 1.2
diff -u -p -r1.2 siginfo.exp
--- testsuite/gdb.base/siginfo.exp 23 Apr 2004 16:44:25 -0000 1.2
+++ testsuite/gdb.base/siginfo.exp 29 Apr 2006 23:11:21 -0000
@@ -75,6 +75,10 @@ gdb_expect_list "backtrace for nexti" ".
 # Check that GDB can step the inferior back to main
 set test "step out of handler"
 gdb_test_multiple "step" "${test}" {
+    -re "Could not insert single-step breakpoint.*$gdb_prompt $" {
+	setup_kfail sparc*-*-openbsd* gdb/1736
+	fail "$test (could not insert single-step breakpoint)"
+    }
     -re "done = 1;.*${gdb_prompt} $" {
 	send_gdb "$i\n"
 	exp_continue
Index: testsuite/gdb.base/sigstep.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/sigstep.exp,v
retrieving revision 1.10
diff -u -p -r1.10 sigstep.exp
--- testsuite/gdb.base/sigstep.exp 18 Jul 2005 19:23:54 -0000 1.10
+++ testsuite/gdb.base/sigstep.exp 29 Apr 2006 23:11:22 -0000
@@ -79,6 +79,10 @@ proc advance { i } {
 
     set test "$prefix; leave handler"
     gdb_test_multiple "$i" "${test}" {
+	-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
+	    setup_kfail "sparc*-*-openbsd*" gdb/1736
+	    fail "$test (could not insert single-step breakpoint)"
+	}
 	-re "done = 1;.*${gdb_prompt} $" {
 	    send_gdb "$i\n"
 	    exp_continue -continue_timer
@@ -122,6 +126,10 @@ proc advancei { i } {
             fail "$test (could not set breakpoint)"
 	    return
         }
+	-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
+	    setup_kfail "sparc*-*-openbsd*" gdb/1736
+	    fail "$test (could not insert single-step breakpoint)"
+	}
 	-re "done = 1;.*${gdb_prompt} $" {
 	    send_gdb "$i\n"
 	    exp_continue -continue_timer


  reply	other threads:[~2006-04-29 23:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-25 20:40 Mark Kettenis
2006-04-25 21:02 ` Daniel Jacobowitz
2006-04-25 21:55   ` Mark Kettenis
2006-04-30  3:20     ` Mark Kettenis [this message]
2006-05-01 13:54       ` Daniel Jacobowitz
2006-05-01 16:43         ` Mark Kettenis

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=200604292314.k3TNE3uH012648@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=drow@false.org \
    --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