From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25957 invoked by alias); 23 Jun 2005 20:39:35 -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 25898 invoked by uid 22791); 23 Jun 2005 20:39:31 -0000 Received: from smtp106.mail.sc5.yahoo.com (HELO smtp106.mail.sc5.yahoo.com) (66.163.169.226) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Thu, 23 Jun 2005 20:39:31 +0000 Received: (qmail 21284 invoked from network); 23 Jun 2005 20:39:29 -0000 Received: from unknown (HELO ?192.168.3.100?) (jcphillips@216.54.38.110 with plain) by smtp106.mail.sc5.yahoo.com with SMTP; 23 Jun 2005 20:39:29 -0000 Message-ID: <42BB1D8C.5020203@yahoo.com> Date: Thu, 23 Jun 2005 20:39:00 -0000 From: Chad Phillips User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 CC: ramana.radhakrishnan@codito.com, gdb@sources.redhat.com Subject: Re: single-stepping remote target fails References: <42BAD2C4.3070802@yahoo.com> <42BAD801.1000509@yahoo.com> <1119545687.15278.62.camel@localhost.localdomain> In-Reply-To: <1119545687.15278.62.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg00213.txt.bz2 > On Thu, Jun 23, 2005 at 01:06:42PM -0400, Chad Phillips wrote: >> Sending packet: $s#73...Ack >> Packet received: S00 >> Sending packet: $p40#d4...Ack >> Packet received: 0000438E >> >> Program received signal 0, Signal 0. > > You should be returning S05, SIGTRAP. > Fantastic! That solved my problem. Now, gdb continues to step to the next source instruction. Thanks! BTW, the documentation for the remote protocol simply says that the signal number is 'poorly defined', and in general to use UNIX conventions. I made the incorrect assumption that the signal number is irrelevant. Are there other signal numbers that have significance to GDB? >> GDB never sends a 'Z1' packet to set a hardware breakpoint as part of >> the step. > > Why should it? Your stub claims to support hardware single step which > does not require a breakpoint. Got it. I understand now. Now I just have to figure out the prologue thing. Thanks again. -Chad