From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8940 invoked by alias); 24 Jun 2002 22:07:17 -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 8916 invoked from network); 24 Jun 2002 22:07:14 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 24 Jun 2002 22:07:14 -0000 Received: from cs2876-108.austin.rr.com ([24.28.76.108] helo=branoic) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17Mbz9-0008WH-00; Mon, 24 Jun 2002 17:07:00 -0500 Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17Mbyf-0008CX-00; Mon, 24 Jun 2002 18:06:29 -0400 Date: Mon, 24 Jun 2002 15:07:00 -0000 From: Daniel Jacobowitz To: Peter Barada Cc: Peter.Barada@motorola.com, gdb@sources.redhat.com Subject: Re: Torubles with remote stub for m68k Message-ID: <20020624220628.GB31470@branoic.them.org> Mail-Followup-To: Peter Barada , Peter.Barada@motorola.com, gdb@sources.redhat.com References: <200206242104.g5OL4pY06652@hyper.wm.sps.mot.com> <20020624211258.GA30001@branoic.them.org> <200206242140.g5OLe0L06792@hyper.wm.sps.mot.com> <200206242156.g5OLumH25691@hyper.wm.sps.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206242156.g5OLumH25691@hyper.wm.sps.mot.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-06/txt/msg00231.txt.bz2 On Mon, Jun 24, 2002 at 05:56:48PM -0400, Peter Barada wrote: > > >>> When I execute that with gdb-5.1.1, it attempts to step the processor > >>> without removing the trap instruction so the target processor never > >>> steps past the trap instruction. > >> > >>You also should try with 5.2 or CVS rather than 5.1.1, probably... > > > >I'm grabbing and building it now. I'll post an update tomorrow. > > > > I got to it quicker than I thought. Nope, same problem as with gdb-5.1.1: > > [Switching to thread 1 (Thread 9)]#0 FRSfindfont ( > name=0x1fd6b70 "AlbertusMT", idptr=0x1fd6b4c, ftype=0x1fd6b50, > fclass=0x1fd6b54, font_mat=0x4c589c, painttype=0x1fd6b58, > fontname=0x1fd6b5c) at ../pdi/fntsockt.c:604 > 604 if (fs_first_unused == (FRS_ID *) NULL) > (gdb) show version > GNU gdb 5.2 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-elf". > (gdb) set debug remote 1 > (gdb) si > Sending packet: $Hc9#e4...Ack > Packet received: OK > Sending packet: $s#73...Ack > Packet received: T05thread:9; > Sending packet: $g#67...Ack > Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6ab04084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 > 604 if (fs_first_unused == (FRS_ID *) NULL) > (gdb) p/x $pc > $1 = 0x3af3c > (gdb) si > Sending packet: $s#73...Ack > Packet received: T05thread:9; > Sending packet: $g#67...Ack > Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6aac4084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 > 604 if (fs_first_unused == (FRS_ID *) NULL) > (gdb) p/x $pc > $2 = 0x3af3c > (gdb) > > With gdb-5, if the stub doesn't use breakpoint registers, is it gdb's > responsibility to save/restore the brekpoint across a 's' packet, or > is that the stub's responsibility? > > Any help is appreciated! If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then it is the client's responsibility to clear it. It would be nice to know why that isn't happening. To observe it in action you can use gdbserver on a GNU/Linux system... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer