Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Fabian Cenedese <Cenedese@indel.ch>
To: gdb@sources.redhat.com
Subject: Re: MI set thread command
Date: Wed, 08 Sep 2004 07:46:00 -0000	[thread overview]
Message-ID: <5.2.0.9.1.20040908083752.01d17910@NT_SERVER> (raw)
In-Reply-To: <20040907170823.GA8884@nevyn.them.org>


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



  reply	other threads:[~2004-09-08  7:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-07  9:03 Fabian Cenedese
2004-09-07 17:08 ` Daniel Jacobowitz
2004-09-08  7:46   ` Fabian Cenedese [this message]
2004-09-08 13:05     ` Daniel Jacobowitz
2004-09-08 13:52       ` Fabian Cenedese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5.2.0.9.1.20040908083752.01d17910@NT_SERVER \
    --to=cenedese@indel.ch \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox