RFC: Always use at least schedlock_step for software single step targets

[Daniel Jacobowitz <drow at mvista dot com>]

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;
 	}