Re: MI set thread command

[Daniel Jacobowitz <drow@false.org>]

On Wed, Sep 08, 2004 at 09:45:30AM +0200, Fabian Cenedese wrote:
> (gdb) s
> Sending packet: $vCont?#49...Ack
> -- test if vCont is supported
> Packet received: vCont;c;s
> Packet vCont (verbose-resume) is NOT supported
> -- why test for single actions if all are necessary? could vCont be expanded?

That's right, it's for future expansion.

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

> 
> 
> Sending packet: $Hc0#db...Ack
> Packet received: OK
> -- select thread with id 0 for cont/step
> 
> Sending packet: $S04#b7...Ack
> -- step with signal 04 (SIGILL...?)
> Packet received:
> Can't send signals to this remote system.  SIGILL not sent.
> -- nope, signals are not supported on the embedded system
> 
> Sending packet: $s#73...Ack
> -- step normal
> 
> 
> Hc Zero means "pick any thread". Why should this be when I want to
> single-step exactly thread 23 and no other? Does this only work with
> vCont (and not s)?

Correct.

> I then implemented all vCont actions and got to this:
> 
> 
> ->$vCont;s:d270;c#8d
> <-$S05#b8

You may want to implement T...

> 
> ->$g#67
> <-$00000000001649e000164ae0001...
> 
> 
> 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.

-- 
Daniel Jacobowitz