From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9982 invoked by alias); 8 Sep 2004 13:05:27 -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 9919 invoked from network); 8 Sep 2004 13:05:11 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 8 Sep 2004 13:05:11 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1C528M-0004Dl-RQ; Wed, 08 Sep 2004 09:05:10 -0400 Date: Wed, 08 Sep 2004 13:05:00 -0000 From: Daniel Jacobowitz To: Fabian Cenedese Cc: gdb@sources.redhat.com Subject: Re: MI set thread command Message-ID: <20040908130510.GA16046@nevyn.them.org> Mail-Followup-To: Fabian Cenedese , gdb@sources.redhat.com References: <5.2.0.9.1.20040907104922.01cfa2a8@NT_SERVER> <5.2.0.9.1.20040907104922.01cfa2a8@NT_SERVER> <5.2.0.9.1.20040908083752.01d17910@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.1.20040908083752.01d17910@NT_SERVER> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-09/txt/msg00064.txt.bz2 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