Inadvertently run inferior threads

[Eli Zaretskii]

> Date: Mon, 15 Jun 2015 18:56:30 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb@sourceware.org
> 
> On 06/15/2015 06:21 PM, Eli Zaretskii wrote:
> >> Date: Mon, 15 Jun 2015 16:28:14 +0100
> >> From: Pedro Alves <palves@redhat.com>
> >> CC: gdb@sourceware.org
> >>
> >>>> So that should mean that even for GNU/Linux, it should be possible
> >>>> to end in the exact same, when any thread other than the one that we
> >>>> had started the infcall in reports an event that doesn't cause a stop.
> >>>> E.g., a thread specific breakpoint, a "handle nostop" signal, etc.
> >>>
> >>> Does that involve minus_one_ptid on GNU/Linux as well?  If not, that
> >>> call will not mark all threads as running, will it?
> >>
> >> It does.  user_visible_resume_ptid returns the same irrespective
> >> of target_can_async.
> > 
> > Then how come your test program ended up showing just that additional
> > thread running?  You even said you couldn't explain why I saw all my
> > threads running on Windows.
> 
> Because linux-nat.c does not report any event to infrun when a
> thread is created, it just immediately goes back to waiting, unlike
> windows-nat.c, which reports TARGET_WAITKIND_SPURIOUS.  By previous
> test program did not have the new thread trip on any event after
> its creation.

Then perhaps the right solution is not to call discard_cleanups at
that point under any condition, always call do_cleanups.  After all,
all the threads are stopped at that point, so why not register that?