From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13089 invoked by alias); 18 Feb 2003 16:51:44 -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 13075 invoked from network); 18 Feb 2003 16:51:43 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 18 Feb 2003 16:51:43 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18lCrH-00041G-00 for ; Tue, 18 Feb 2003 12:52:47 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18lAy5-0007MW-00 for ; Tue, 18 Feb 2003 11:51:41 -0500 Date: Tue, 18 Feb 2003 16:51:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Is stub support for the 's' packet optional or required? Message-ID: <20030218165140.GA17229@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20030218020408.EE11C3CF2@localhost.redhat.com> <1030218162957.ZM3642@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1030218162957.ZM3642@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00308.txt.bz2 On Tue, Feb 18, 2003 at 09:29:58AM -0700, Kevin Buettner wrote: > On Feb 17, 9:04pm, Andrew Cagney wrote: > > > If GDB implements software single step, then the `s' packet is never > > used. Consequently, requiring the unconditional implementation of "s" > > makes little sense. > > What about the situation where GDB implements software single step AND > the stub implements the 's' packet? Shouldn't GDB at least attempt to > see if the stub supports the 's' packet before deciding to never send > it? In my humble opinion, SOFTWARE_SINGLE_STEP should affect native code and not remote; I'm much too intimidated by the stop and resume logic to actually change it myself, though. If there were less global state around infrun this might be easier. > [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? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer