From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30618 invoked by alias); 25 Jun 2002 15:13:13 -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 30609 invoked from network); 25 Jun 2002 15:13:11 -0000 Received: from unknown (HELO motgate.mot.com) (129.188.136.100) by sources.redhat.com with SMTP; 25 Jun 2002 15:13:11 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA25367; Tue, 25 Jun 2002 08:13:09 -0700 (MST)] Received: [from mail.wm.sps.mot.com ([199.10.246.2]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA24268; Tue, 25 Jun 2002 08:13:08 -0700 (MST)] Received: from hyper.wm.sps.mot.com (hyper.wm.sps.mot.com [199.10.246.43]) by mail.wm.sps.mot.com (8.9.3/8.9.3) with ESMTP id LAA14511; Tue, 25 Jun 2002 11:12:58 -0400 Received: by hyper.wm.sps.mot.com (8.11.2) id g5PFCxZ26374; Tue, 25 Jun 2002 11:12:59 -0400 Date: Tue, 25 Jun 2002 08:13:00 -0000 Message-Id: <200206251512.g5PFCxZ26374@hyper.wm.sps.mot.com> From: Peter Barada To: drow@mvista.com CC: Peter.Barada@motorola.com, Peter.Barada@motorola.com, gdb@sources.redhat.com In-reply-to: <20020624220628.GB31470@branoic.them.org> (message from Daniel Jacobowitz on Mon, 24 Jun 2002 18:06:29 -0400) Subject: Re: Torubles with remote stub for m68k 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> <20020624220628.GB31470@branoic.them.org> X-SW-Source: 2002-06/txt/msg00243.txt.bz2 >> 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... Huh? That doesn't make sense(at least to me)... Why would gdb go to all the trouble of writing the breakpoint and the force the stub to remove it? Does the stub have to remove the breakpoint when gdb is reading memory(say for x/10i $pc)? How can the stub manage an unbounded number of breakpoints this way(wouldn't the stub be required to allocate memory)? Where in the documentation is this 'symbiosis' mentioned where gdb sets breakpoints and the stub is responsible for removing them while stepping? Besides, this stub works fine with gdb-4.16 and gdb-4.18, so what's changed? I can see that if the 'Z' commands are used to set breakpoints then the stub is responsible for managing them, but not the 'M' command... Again, any help is appreciated! -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)