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

[Mark Kettenis <kettenis@chello.nl>]

   Date: Wed, 23 Oct 2002 00:26:15 -0400
   From: Daniel Jacobowitz <drow@mvista.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;

I'm fairly certain it's not without reason that I wrote this comment
as it is.

   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.

I don't see directly why, but I wouldn't be surprised by it.

   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.

Indeed, there's something wrong here.

   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.

There is one thing that might be affected.  Suppose you have a signal
such as SIGUSR1 that stops the inferior but is also passed on to the
inferior.  If a multi-threaded program gets this signal, GDB will
stop.  If you now change the current thread to some other thread and
try to single-step.  Will the signal be delivered to the origional
thread?

If your patch doesn't affect this, I think your patch is OK to check
in.  Otherwise we'll have to think about this a bit more.

Mark