MI set thread command

[Fabian Cenedese]

>> from remote.c
>>       /* If s, S, c, and C are not all supported, we can't use vCont.  Clearing
>>          BUF will make packet_ok disable the packet.  */
>
>I think this could be fixed, since we support running without S and C,
>and on some targets even without s.  I just didn't have a reason to do
>it when I added vCont.

I now added S and C but discard the signal, so S=s and C=c, seems to work.

>> ->$vCont;s:d270;c#8d
>> <-$S05#b8
>
>You may want to implement T...

I already have (as visible in my example).

>> So gdb debugs a thread and asks registers, and the registers of course need to
>> come from the same thread. Which registers do I need to return now? The ones
>> from the last Hgt command? Or the ones from the last vCont;s command? Or
>> should they be the same anyway?
>
>This is a little fuzzy in the protocol; might want to take a look at
>how gdbserver handles it.  I know that if the resume reply specifies
>thread:, that sets GDB's idea of where to expect registers from.  If it
>doesn't, I am not sure what happens.

Ok, back to remote.c and gdbserver then :)

Thanks

bye  Fabi