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
next prev parent 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