Re: [PATCH 3/8] Set general_thread after restart

[Yao Qi <qiyaoltc at gmail dot com>]

Pedro Alves <palves@redhat.com> writes:

> I think this should be:
>
>   if (last_status.kind == TARGET_WAITKIND_STOPPED)
>     {
>       /* Stopped at the first instruction of the target process.  */
>       general_thread = last_ptid;
>     }
>   else
>     {
>       /* Something went wrong.  */
>       general_thread = null_ptid;
>     }
>

OK, I'll fix it in the commit ready to push.

>> +# Test running programs using extended-remote.
>
> Comment looks stale.  Looks like I missed pointing out the same
> in patch #2.
>

I'll remove it.

> Otherwise looks good to me.
>
> (I think it's likely we have lots of stale-data bugs on the
> gdb side after R, as we don't resync much.  It previously crossed my mind
> that immediately after sending R, gdb should refresh all its
> remote state anew, like if it had just disconnected and then reconnected.
> That is, do most of what remote_start_remote does, except the
> connection-specific details (qSupported, etc.)
> Hard to justify the effort though -- I don't think I ever worked with
> a stub that relies on R.)

Even GDB refreshes all its state after sending R packet, we still need
some way to test GDB and GDBserver with R packet used.  Otherwise, it
will be bit-rotten in the future.

GDBserver has already had an option --disable-packet, so that we can
extend it to force GDBserver/GDB use R packet.  However, I don't think
we use --disable-packet much in our testing, at least I don't.  Probably
we can hack native-gdbserver.exp to run tests in a loop and pass
different --disable-packet=FOO to GDBserver in each iteration.

-- 
Yao (éå)