RFA: lin-lwp bug with software-single-step or schedlock

[Daniel Jacobowitz <drow at mvista dot com>]

This bug was noticed on MIPS, because MIPS GNU/Linux is
SOFTWARE_SINGLE_STEP_P.  There's a comment in lin_lwp_resume:

  /* Apparently the interpretation of PID is dependent on STEP: If
     STEP is non-zero, a specific PID means `step only this process
     id'.  But if STEP is zero, then PID means `continue *all*
     processes, but give the signal only to this one'.  */
  resume_all = (PIDGET (ptid) == -1) || !step;

Now, I did some digging, and I believe this comment is completely incorrect. 
Saying "signal SIGWINCH" causes PIDGET (ptid) == -1, and it is assumed the
signal will be delivered to inferior_ptid.  There's some other problem there
- I think I've discovered that we will neglect to single-step over a
breakpoint if we are told to continue with a signal, which is a bit dubious
of a decision - but by and large it works as expected.

So if STEP is 0, we always resume all processes.  STEP at this point _only_
refers to whether we want a PTRACE_SINGLESTEP or equivalent;
SOFTWARE_SINGLE_STEP has already been handled.  We can't make policy
decisions based on STEP any more.

I tried removing the || !step.  It's pretty hard to tell, since there are
still a few non-deterministic failures on my test systems (which is what I
was actually hunting when I found this!) but I believe testsuite results are
improved on i386.  One run of just the thread tests (after the patch in my
last message, which I've committed), shows that these all got fixed:

FAIL: gdb.threads/schedlock.exp: other thread 0 didn't run (ran)
FAIL: gdb.threads/schedlock.exp: other thread 2 didn't run (ran)
FAIL: gdb.threads/schedlock.exp: other thread 3 didn't run (ran)
FAIL: gdb.threads/schedlock.exp: other thread 4 didn't run (ran)
FAIL: gdb.threads/schedlock.exp: other thread 5 didn't run (ran)

with my change:
# of expected passes            188
# of unexpected failures        3

without:
# of expected passes            183
# of unexpected failures        7

There's still two that look like test issues rather than bugs, one that is
fixed by a patch Kevin posted a long time ago, and one in print-threads.exp
that I'm not sure of the cause for yet.



On MIPS it's more pronounced, as I'd expect.
with my change:
# of expected passes            170
# of unexpected failures        12

without:
# of expected passes            114
# of unexpected failures        41


At least one of the MIPS issues remaining appears to be hitting the software
single step breakpoint in the wrong thread.  It doesn't seem to be marked as
thread-specific, and it should be.  I'll follow up on that later.


That was the long version.  Here's the short version.  OK to apply?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


2002-10-23  Daniel Jacobowitz  <drow@mvista.com>

	* lin-lwp.c (lin_lwp_resume): Remove resume_all test for !step.

Index: lin-lwp.c
===================================================================
RCS file: /cvs/src/src/gdb/lin-lwp.c,v
retrieving revision 1.35
diff -u -p -r1.35 lin-lwp.c
--- lin-lwp.c	27 Aug 2002 22:37:06 -0000	1.35
+++ lin-lwp.c	23 Oct 2002 04:23:13 -0000
@@ -579,11 +579,8 @@ lin_lwp_resume (ptid_t ptid, int step, e
   struct lwp_info *lp;
   int resume_all;
 
-  /* Apparently the interpretation of PID is dependent on STEP: If
-     STEP is non-zero, a specific PID means `step only this process
-     id'.  But if STEP is zero, then PID means `continue *all*
-     processes, but give the signal only to this one'.  */
-  resume_all = (PIDGET (ptid) == -1) || !step;
+  /* A specific PTID means `step only this process id'.  */
+  resume_all = (PIDGET (ptid) == -1);
 
   if (resume_all)
     iterate_over_lwps (resume_set_callback, NULL);