From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30707 invoked by alias); 18 Feb 2003 20:23:35 -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 30684 invoked from network); 18 Feb 2003 20:23:34 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 18 Feb 2003 20:23:34 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18lGAG-0004Ql-00; Tue, 18 Feb 2003 16:24:37 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18lEH2-0002QH-00; Tue, 18 Feb 2003 15:23:28 -0500 Date: Tue, 18 Feb 2003 20:23:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: Is stub support for the 's' packet optional or required? Message-ID: <20030218202328.GA32467@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb@sources.redhat.com References: <20030218020408.EE11C3CF2@localhost.redhat.com> <1030218162957.ZM3642@localhost.localdomain> <20030218165140.GA17229@nevyn.them.org> <1030218200628.ZM4508@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1030218200628.ZM4508@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00317.txt.bz2 On Tue, Feb 18, 2003 at 01:06:28PM -0700, Kevin Buettner wrote: > On Feb 18, 11:51am, Daniel Jacobowitz wrote: > > > > [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? > > Different things happen. Specifically, GDB was getting a SIGTRAP due to > one of the other threads hitting the software single step breakpoint. > This meant that I was unable to step through the function that I was > attempting to debug when GDB was setting the software single step > breakpoints. When I moved that functionality (software single step) > to the debug agent, I was able to step through the code of interest > without any problem. That's a bug in software single step handling; I bet it shows up now too, just less often (because of latency changes). I think it's as simple as marking the single-step breakpoint thread-specific in the normal way, but it might be a little more complicated... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer