[PATCH 04/10] struct resumed_pending_vcont_info -> struct resume_info

[Simon Marchi]

> @@ -6467,7 +6474,8 @@ remote_target::resume (ptid_t ptid, int step, enum gdb_signal siggnal)
>  
>    /* Update resumed state tracked by the remote target.  */
>    for (thread_info *tp : all_non_exited_threads (this, ptid))
> -    get_remote_thread_info (tp)->set_resumed ();
> +    get_remote_thread_info (tp)->set_resumed (false, GDB_SIGNAL_0);
> +  remote_thr->set_resumed (step, siggnal);

This is really a small detail, but I would find it a bit easier to
understand like:

  for (thread_info *tp : all_non_exited_threads (this, ptid))
    if (get_remote_thread_info (tp) == remote_thr)
      get_remote_thread_info (tp)->set_resumed (step, siggnal);
    else
      get_remote_thread_info (tp)->set_resumed (false, GDB_SIGNAL_0);

Maybe this wasn't possible for some reason, but I imagine that we could
add an assertion in set_resumed:

  gdb_assert (m_resume_state != resume_state::RESUMED);

to indicate that a RESUMED -> RESUMED state transition is not a valid
one (if we were to draw the state machine diagram, there would be no
arrow from RESUMED to RESUMED).  So, I would find it more logical to
write the code with that in mind.

> @@ -6926,7 +6931,7 @@ remote_target::remote_stop_ns (ptid_t ptid)
>  	       queue, we'll end up reporting a stop event to the core
>  	       for that thread while it is running on the remote
>  	       target... that would be bad.  */
> -	    remote_thr->set_resumed ();
> +	    remote_thr->set_resumed (false, GDB_SIGNAL_0);

Could it happen that a thread going though this, in the
RESUMED_PENDING_VCONT state, would have step == true?  And if so, should
be keep step == true when moving it to the RESUMED state?  It might not
matter today, but it might one day.

Other than these minor comments, the patch LGTM.

Simon