Re: Inadvertently run inferior threads

[Pedro Alves <palves@redhat.com>]

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:

...
      /* Now stop all other LWP's ...  */
      iterate_over_lwps (minus_one_ptid, stop_callback, NULL);

      /* ... and wait until all of them have reported back that
	 they're no longer running.  */
      iterate_over_lwps (minus_one_ptid, stop_wait_callback, NULL);
...

> Does the same happen on GNU/Linux (and other systems that support
> asynchronous execution)?  

Yes.  It's gdb's own code that does it, but from infrun.c's
perspective, it's the same.

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

(BBL to reply to the rest.)

Thanks,
Pedro Alves