Re: Inadvertently run inferior threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 15 Jun 2015 14:17:55 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb@sourceware.org
> 
> On 06/11/2015 02:41 PM, Eli Zaretskii wrote:
> 
> > And I have a question about your description of what happens on
> > GNU/Linux.  You say:
> > 
> >>  #4 - result: _new_ threads end up in "running" state, even though they
> >>     are stopped.
> > 
> > My question is this: who or what stops the new threads that were
> > started by the function we infcall'ed?  I know who stops them on
> > MS-Windows: the OS.
> 
> GDB does, from within the target's target_wait implementation.
> For Linux, it's in linux-nat.c:linux_nat_wait_1:

I guess this happens unless the breakpoint was thread-specific, right?
Otherwise the async execution would be much less useful, I presume.
But I digress.

> > If so, I don't understand why we suppress
> > the stopped <-> running transitions when in infcall.  Or at least the
> > running -> stopped transition.  The comment in normal_stop tries to
> > explain this:
> 
> Say you have a breakpoint with a condition that does an infcall, like:
> 
>  int return_false (void) { return 0 };
> 
>  (gdb) b somewhere_in_a_loop if return_false()
>  (gdb) c
> 
> >From the perspective of the user, the thread is always running
> after that "c".  The breakpoint stops for both "somewhere_in_a_loop" and
> for the infcall's dummy breakpoint are all internal run control
> machinery details.

I'm not sure I follow.  From this user's (admittedly semi-naive) POV,
what happens with such a breakpoint is this:

  . Inferior hits the breakpoint and stops; the thread is now "not
    running".

  . GDB gets control and evaluates the condition.

  . When GDB issues the infcall, as part of evaluating the condition,
    the thread resumes -- now it is "running".

  . The thread that runs the infcall reaches the end of the function
    and stops at the temporary breakpoint GDB inserted there -- the
    thread is again "not running".

  . GDB evaluates the return value, decides that the condition was not
    fulfilled, and resumes the inferior -- the thread is now "running"
    again.  Or GDB decides that the condition _was_ fulfilled, in
    which case the thread stays at its "not running" state.

So it sounds to me that if we faithfully reflect the actual running
state of the thread during this scenario, without any exceptions or
exemptions, we are good.  You say "internal run control machinery
details", but since these controls actually run and stop user threads,
I don't see why we should work so hard to conceal them, and in the
process shoot ourselves in the foot.

What am I missing?

Thanks for taking the time to explain these details.