From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4508 invoked by alias); 4 Nov 2005 15:46:34 -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 4480 invoked by uid 22791); 4 Nov 2005 15:46:31 -0000 Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 04 Nov 2005 15:46:31 +0000 Received: from espanola ([192.168.1.110]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 15:46:29 +0000 From: "Dave Korn" To: "'Daniel Jacobowitz'" , "'Simon Richter'" Cc: "'Efim Monjak'" , Subject: RE: break of close loop Date: Fri, 04 Nov 2005 15:46:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20051104153944.GA4309@nevyn.them.org> Message-ID: X-SW-Source: 2005-11/txt/msg00109.txt.bz2 '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. cheers, DaveK -- Can't think of a witty .sigline today....