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

[Yao Qi <qiyaoltc at gmail dot com>]

Pedro Alves <palves@redhat.com> writes:

> I find these descriptions useful.  Could you instead write something
> like:
>
>  "Test restarting programs with the R packet."
>
> ?

OK.

>
>> 
>>> 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.
>
> Sounds like we're talking past each other.
> Not sure what I said that made it sounds like that
> idea would obviate the need for the test -- I think your new
> test is great.

No :)  I have a habit that think about how to test the change before I
start to change.  This leads me there.

>
> I meant something like gdb itself, around extended_remote_restart, calling
> into a new function factored out from remote_start_remote.
> This is because the R packet is documented as having no reply, like
> 'k', no doubt because it assumes the remote target can really hard reset
> after the R packet.  But let's forget it; hardly worth it to spend time
> on it right now.

Yes, that is a good idea, and you are right that it is hard to justify
the effort now.

-- 
Yao (éå)