From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26092 invoked by alias); 18 Feb 2003 21:43:45 -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 26085 invoked from network); 18 Feb 2003 21:43:45 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 21:43:45 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1ILhjK18392 for ; Tue, 18 Feb 2003 16:43:45 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1ILhha28877; Tue, 18 Feb 2003 16:43:43 -0500 Received: from localhost.localdomain (vpn50-1.rdu.redhat.com [172.16.50.1]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1ILhg503564; Tue, 18 Feb 2003 16:43:43 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1ILhb604872; Tue, 18 Feb 2003 14:43:37 -0700 Date: Tue, 18 Feb 2003 21:43:00 -0000 From: Kevin Buettner Message-Id: <1030218214337.ZM4871@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: Is stub support for the 's' packet optional or required?" (Feb 18, 4:07pm) References: <20030218020408.EE11C3CF2@localhost.redhat.com> <1030218162957.ZM3642@localhost.localdomain> <20030218165140.GA17229@nevyn.them.org> <3E52A0A7.5020104@redhat.com> To: Andrew Cagney , Daniel Jacobowitz , Kevin Buettner Subject: Re: Is stub support for the 's' packet optional or required? Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00323.txt.bz2 On Feb 18, 4:07pm, Andrew Cagney wrote: > # FIXME/cagney/2001-01-18: This should be split in two. A target method > that indicates if the target needs software single step. An ISA method > to implement it. This one puzzles me. How can gdb find out if a target (e.g. remote stub) can single step without first attempting the operation? > # FIXME/cagney/2001-01-18: This should be replaced with something that > inserts breakpoints using the breakpoint system instead of blatting > memory directly (as with rs6000). I agree with this and am looking into doing it. > # FIXME/cagney/2001-01-18: The logic is backwards. It should be asking > if the target can single step. If not, then implement single step using > breakpoints. It seems to me that this could be rolled into the first comment, above. > (All taken with a grain of salt.) After (re)reading these comments, I came up with a different strategy (which I'm presently rethinking). Instead of asking the target if it can single step, it might be better to push the SOFTWARE_SINGLE_STEP invocation down to the bottom-most target resume() (i.e, child_resume() for many natives). At the moment, it's in resume() in infrun.c. (There is also a call which removes the breakpoints, but, presumably if we get things using the breakpoint system, this can be replaced with something better.) As I said, I'm presently rethinking this. The first step is to figure out how to make software single step properly use the breakpoint machinery. > >> [For remote MIPS/Linux targets, I've found some cases where GDB's > >> implementation of software singlestep causes some undesirable behavior > >> when doing the 'stepi' operation through some code that's hit by a number > >> of threads. Yet, when software single step is implemented in the debug > >> agent (and disabled in GDB), the debugging behavior is much more useful > >> (and sensible).] > > > > > > Is it just slow, or do different things actually happen? > > It is just very slow. I was actually seeing different behavior. Kevin