MI set thread command

MI set thread command

[Fabian Cenedese]

Hi

The manual says for the MI set thread command:
Hct - where c should be 'c' for step and continue, but 'g' for other operations.

What are does other operations? Reading registers? When does gdb use
the one or the other? What is used if I issue "thread xx" on the command line?
So far I couldn't quite make it out from watching the protocols.

Thanks

bye  Fabi

Re: MI set thread command

[Daniel Jacobowitz]

On Tue, Sep 07, 2004 at 11:02:35AM +0200, Fabian Cenedese wrote:
> Hi
> 
> The manual says for the MI set thread command:
> Hct - where c should be 'c' for step and continue, but 'g' for other operations.

This is not an MI command.  MI is the machine-interface used to drive
GDB, mostly from GUIs; you're asking about the remote protocol.

> What are does other operations? Reading registers? When does gdb use
> the one or the other? What is used if I issue "thread xx" on the command line?
> So far I couldn't quite make it out from watching the protocols.

Yes, usually for reading registers.  If you couldn't make it out from
reading the remote protocol logs I recommend reading remote.c.  It's
fairly easy to follow this bit.

-- 
Daniel Jacobowitz

Re: MI set thread command

[Fabian Cenedese]

>> The manual says for the MI set thread command:
>> Hct - where c should be 'c' for step and continue, but 'g' for other operations.
>
>This is not an MI command.  MI is the machine-interface used to drive
>GDB, mostly from GUIs; you're asking about the remote protocol.

Yes, of course. As I work with both I got the names mixed up, sorry.

>> What are does other operations? Reading registers? When does gdb use
>> the one or the other? What is used if I issue "thread xx" on the command line?
>> So far I couldn't quite make it out from watching the protocols.
>
>Yes, usually for reading registers.  If you couldn't make it out from
>reading the remote protocol logs I recommend reading remote.c.  It's
>fairly easy to follow this bit.

Ah yeah, remote.c, already know that one :)

I have here a short example I didn't understand. First I select thread 23 and
then want to do a single-step on it. But gdb tells the stub to use thread 0
(inserted my own comments with -- ) :

(gdb) thread 23
Sending packet: $T0000d270#11...Ack
Packet received: OK
-- thread 23 with id 0000d270 exists

Sending packet: $Hgd270#ac...Ack
Packet received: OK
-- select thread with id d270 for various operations

Sending packet: $g#67...Ack
Packet received: 00000ce400164...
-- get registers from this thread

[Switching to thread 23 (Thread 53872)]#0  0x0009886c in CISMInterpreter::Getuint16 (this=0xce4, aAddress=0x1638f8)
    at N:/Temp/JavaProjectsCpp/inos3/os/inos/inc/inos_ism.h:510
510                     {

(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?

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


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)?

I then implemented all vCont actions and got to this:


->$vCont;s:d270;c#8d
<-$S05#b8

->$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?

Thanks

bye  Fabi

Re: MI set thread command

[Daniel Jacobowitz]

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

Re: 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