Re: attach_command_post_wait oddity

[Pedro Alves <palves at redhat dot com>]

On 07/30/2014 12:10 AM, Doug Evans wrote:
> Hi.
> 
> I don't understand this snippet from attach_command_post_wait:
> [this is the !async_exec case, i.e. no "&"]
> 
>       /* In all-stop, by definition, all threads have to be already
> 	 stopped at this point.  In non-stop, however, although the
> 	 selected thread is stopped, others may still be executing.
> 	 Be sure to explicitly stop all threads of the process.  This
> 	 should have no effect on already stopped threads.  */
>       if (non_stop)
> 	target_stop (pid_to_ptid (inferior->pid));
> 
> All target_stop does is (essentially) send SIGSTOP, it doesn't wait
> for threads to stop.
> 
> So who does?

Nothing does, the event loop handles the other threads' stops as
asynchronous stops, similar to "interrupt -a".   Currently,
you're given the prompt immediately (one thread stopped), and then the
other threads report stops asynchronously.

> 
> The above code is immediately followed by:
> 
>       /* Tell the user/frontend where we're stopped.  */
>       normal_stop ();
>       if (deprecated_attach_hook)
> 	deprecated_attach_hook ();
> 
> and that's it.  So there's no waiting for the inferior to stop here.
> Either the call to target_stop is redundant (and can be deleted), or
> there's missing code to wait for threads to stop, or I'm missing something.
> 
> After some research, I think the *only* case where the above target_stop
> call *could* do something useful 
> is via this code in
> remote.c:process_stop_reply:
> 
>       remote_notice_new_inferior (ptid, 0);
> 
> [I wrote out a long winded explanation of why I think that's true,
> but in the end I think it might be quicker to just convince yourself of that.]

We need it for "attach" too.  There's no requirement that target_attach finds
threads stopped (see description of vAttach in the manual).

And, in attach_command, when we do:

	/* The user requested an `attach', so stop all threads of this
	   inferior.  */
	target_stop (pid_to_ptid (ptid_get_pid (inferior_ptid)));

we may not know yet the whole set of threads in the process.  We may
only learn about them when we see the first stop, and manage to
query the list (such as with with libthread_db, for example, which
only happens in post_create_inferior, when we fetch the list of
shared libraries).  Now, with native debugging on Linux, we happen to
discover threads stopped already, but that's not the case with
all targets.  For those that leave threads running on attach, if
we don't stop them explicitly here too, and we've only discovered
them after target_attach, we'll leave them running free by mistake.

Thanks,
Pedro Alves