Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: RFC: Always use at least schedlock_step for software single step targets
Date: Thu, 05 Jun 2003 14:37:00 -0000	[thread overview]
Message-ID: <20030605143728.GA31355@nevyn.them.org> (raw)

This deserves a bit of explanation.  Andrew, this is the same bug I was
telling you about in the hallway at the Summit.  The fix is a bit different,
though.

Our threading test results have always been fairly bad on targets which use
software single step.  One reason was that we didn't properly associate the
single-step breakpoint with a thread.  So if another thread hit it before
the expected one, then that thread would get a SIGTRAP.  Oops.  Worse, if I
set up thread hopping we'd lose the fact that we were originally
single-stepping a different thread, and lose control of the inferior.

I put together a patch to fix both of these.  It was pretty gross, so I'm
not including it here, but it worked.  It had a different problem, however:
we livelock in schedlock.exp because other threads always hit the breakpoint
before the one we're trying to step.  A similar problem was solved in
lin-lwp by an ad-hoc scheduler, if I recall correctly.  I concluded that the
tradeoffs for implementing this sort of scheduler on a remote stub were too
high, and used this patch instead.  If we're inserting a software single
step breakpoint, be sure to resume only one thread.

Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-06-05  Daniel Jacobowitz  <drow@mvista.com>

	* infrun.c (resume): Always assume schedlock_step for
	software single step.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.109
diff -u -p -r1.109 infrun.c
--- infrun.c	7 May 2003 18:35:57 -0000	1.109
+++ infrun.c	5 Jun 2003 14:30:43 -0000
@@ -625,10 +625,11 @@ resume (int step, enum target_signal sig
 	}
 
       if ((scheduler_mode == schedlock_on) ||
-	  (scheduler_mode == schedlock_step &&
-	   (step || singlestep_breakpoints_inserted_p)))
+	  (scheduler_mode == schedlock_step && step)
+	  || singlestep_breakpoints_inserted_p)
 	{
 	  /* User-settable 'scheduler' mode requires solo thread resume. */
+	  /* Software single-step doesn't work right with multiple threads.  */
 	  resume_ptid = inferior_ptid;
 	}
 


             reply	other threads:[~2003-06-05 14:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-05 14:37 Daniel Jacobowitz [this message]
2003-06-05 18:44 ` Michael Snyder
2003-06-05 18:47   ` Daniel Jacobowitz
2003-06-05 19:04     ` Michael Snyder
2003-06-06 21:36 ` Andrew Cagney
2003-06-06 23:58   ` Daniel Jacobowitz

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=20030605143728.GA31355@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /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