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

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Oct 23, 2002 at 01:32:30AM -0400, Andrew Cagney wrote:
> >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:
> 
> Shouldn't, per the remote.c Hg discussion, the code be changed so that 
> lin_lwp_resume() has complete information and, hence, can correctly 
> determine if resume all/one is needed.

Except the case is a little different - with remote we've never had a
problem figuring out if all/one is needed, only figuring out _which_
thread to signal/treat specially.  The information on whether to resume
one or all is there; it's in ptid, which lin-lwp was misinterpreting. 
We should eventually update the interface to the resume functions to
eliminate this hackery; I was thinking something like:

  void target_resume (ptid_t ptid, int step, int resume_all);

But that can be done as a follow-up.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer