This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: lin-lwp bug with software-single-step or schedlock
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.
Uh, you didn't. I did. You copied it from "lin-thread.c".
And I wrote it because I found it empirically to be true at the time.
> 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.
The whole business is rather unplanned. The exact meaning and
connotation of those variables is nowhere defined in writing.
Mainly it's a matter of keeping consistent with what the code
in gdb expects, which you sometimes have to guess, or learn by
examining an older threaded architecture (eg. solaris).
> 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.
Sounds like something has changed upstream.
> 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?
That's what "prepare_to_proceed" is supposed to take care of.
> 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.
I'll pipe up and comment, as above, but I'll let you two guys
work out the decision between you.
Michael