Re: Inadvertently run inferior threads

[Pedro Alves <palves at redhat dot com>]

On 06/15/2015 04:27 PM, Eli Zaretskii wrote:
>> 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?

No, it always happens.  It's the core of run control that decides
after everything has stopped whether a thread-specific breakpoint
tripped for the wrong thread.

> Otherwise the async execution would be much less useful, I presume.

It's still useful, just not as efficient as you'd hope.

> But I digress.

(
The "[PATCH v4 00/18] All-stop on top of non-stop" series
gives us the optimization you were expecting:

 https://sourceware.org/ml/gdb-patches/2015-05/msg00564.html
)

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

That's what internal "executing" state tracks.

With asynchronous control and background execution, you have to consider
what happens if the user does "info threads" just while GDB is handling
these internal stops.  If the user does "step&" (step in the background,
and give me the prompt right away), and then does "info threads" while the
thread is busy doing the internal single-steps, it'd be highly
confusing to sometimes see the thread as stopped (e.g., if it needed to
be held a bit while another thread steps over a breakpoint) and sometimes
as running.

The user should not be able to issue "continue" right at the time a
thread had stopped for such an internal event, and manage to override
an already ongoing "step".

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

Thanks,
Pedro Alves