attach_command_post_wait oddity

[Doug Evans <dje at google dot com>]

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?

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

If that's correct I'll add some comments to the code so the next time
I read it I won't have to do that research again. :-)

But I'm still confused as to where gdb waits for the inferior to stop here.

Thanks.