From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10729 invoked by alias); 4 Nov 2005 16:00:20 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 10704 invoked by uid 22791); 4 Nov 2005 16:00:16 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 04 Nov 2005 16:00:16 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EY3z8-0001I4-TA; Fri, 04 Nov 2005 11:00:11 -0500 Date: Fri, 04 Nov 2005 16:00:00 -0000 From: 'Daniel Jacobowitz' To: Dave Korn Cc: 'Simon Richter' , 'Efim Monjak' , gdb@sources.redhat.com Subject: Re: break of close loop Message-ID: <20051104160010.GA4912@nevyn.them.org> Mail-Followup-To: Dave Korn , 'Simon Richter' , 'Efim Monjak' , gdb@sources.redhat.com References: <20051104153944.GA4309@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00111.txt.bz2 On Fri, Nov 04, 2005 at 03:46:29PM -0000, Dave Korn wrote: > 'Daniel Jacobowitz' wrote: > > On Fri, Nov 04, 2005 at 04:18:57PM +0100, Simon Richter wrote: > >> Hi, > >> > >> Dave Korn wrote: > >> > >>> The stub is probably implemented by placing a temp breakpoint > >>> immediately after the instruction to be tested, but has negelected the > >>> fact that to handle jumps you may need to place the temp breakpoint > >>> somewhere _other_ than immediately after the instruction, > >> > >> The question at hand appears to be breakpoints placed on top of the > >> instruction being stepped, as the instruction steps back to itself. This > >> is especially common on architectures with a dedicated "decrement and > >> jump if not zero" instruction. > > > > If you have such instructions, and you don't have hardware single step, > > then you need to be prepared to either wait for the instruction to > > finish or else interrupt it. I don't see the problem. > > No, I still think that's a buggy stub; I think that, given a djnz-style > instruction, "stepi" should execute it precisely once (decrement the counter, > keep PC the same if non-zero or advanced to next instruction if counter reg > now == 0), and "nexti" should run it to completion, shouldn't they? That's > certainly how x86 debugging works natively. The lack of hardware single-step > is something the stub should transparently handle. If you feel like defining it as buggy, go ahead. In practice it may not be practical to do this - there's a difference between buggy and sub-ideal. -- Daniel Jacobowitz CodeSourcery, LLC