From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12550 invoked by alias); 8 Sep 2004 13:52:25 -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 12539 invoked from network); 8 Sep 2004 13:52:24 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 8 Sep 2004 13:52:24 -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 i88DqNUq032324 for ; Wed, 8 Sep 2004 15:52:23 +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 15:50:26 +0200 Message-Id: <5.2.0.9.1.20040908154545.01d43318@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Wed, 08 Sep 2004 13:52:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: MI set thread command In-Reply-To: <20040908130510.GA16046@nevyn.them.org> References: <5.2.0.9.1.20040908083752.01d17910@NT_SERVER> <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" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-09/txt/msg00065.txt.bz2 >> 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. I now added S and C but discard the signal, so S=s and C=c, seems to work. >> ->$vCont;s:d270;c#8d >> <-$S05#b8 > >You may want to implement T... I already have (as visible in my example). >> 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. Ok, back to remote.c and gdbserver then :) Thanks bye Fabi