From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15026 invoked by alias); 8 Sep 2004 07:46:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14996 invoked from network); 8 Sep 2004 07:46:03 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 8 Sep 2004 07:46:03 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i887k2ES003280 for ; Wed, 8 Sep 2004 09:46:02 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Wed, 08 Sep 2004 09:44:45 +0200 Message-Id: <5.2.0.9.1.20040908083752.01d17910@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Wed, 08 Sep 2004 07:46:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: MI set thread command In-Reply-To: <20040907170823.GA8884@nevyn.them.org> References: <5.2.0.9.1.20040907104922.01cfa2a8@NT_SERVER> <5.2.0.9.1.20040907104922.01cfa2a8@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-09/txt/msg00062.txt.bz2 >> 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