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

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Oct 23, 2002 at 11:13:22PM +0200, Mark Kettenis wrote:
>    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.

I'm sure - I'd dearly like to know why, since I'm sure it'll bite us
later :)

>    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.

Well, let's see.  There's some interesting behavior here.

- stopped at GDB prompt, thread 8 current
- say "signal SIGWINCH"
- thread 8 gets the signal

- stopped at GDB prompt, thread 8 current
- say "thread 9"
- say "signal SIGWINCH"
- thread 9 gets the signal

- stopped at GDB prompt, thread 8 current
- say "thread 9"
- say "set scheduler-locking on"
- say "stepi"
- thread 9 steps

- thread 8 gets SIGWINCH (which is set to stop print pass in my session)
- thread 8 is current thread at stop
- say "continue"
- thread 8 gets SIGWINCH

- thread 8 gets SIGWINCH
- thread 8 is current thread at stop
- say "thread 9"
- say "continue"
- thread 9 gets SIGWINCH

Oops.  However, this behavior is 100% unchanged by my patch; that is,
it didn't work before either.  Using step instead of continue makes no
difference either.

Is my patch OK in this case?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer