This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI set thread command


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]