From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17901 invoked by alias); 18 Feb 2003 20:06: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 17894 invoked from network); 18 Feb 2003 20:06:35 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 20:06:35 -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 h1IK6ZK24579 for ; Tue, 18 Feb 2003 15:06:35 -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 h1IK6Za01845; Tue, 18 Feb 2003 15:06:35 -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 h1IK6Y520718; Tue, 18 Feb 2003 15:06:34 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1IK6S504509; Tue, 18 Feb 2003 13:06:28 -0700 Date: Tue, 18 Feb 2003 20:06:00 -0000 From: Kevin Buettner Message-Id: <1030218200628.ZM4508@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: Is stub support for the 's' packet optional or required?" (Feb 18, 11:51am) References: <20030218020408.EE11C3CF2@localhost.redhat.com> <1030218162957.ZM3642@localhost.localdomain> <20030218165140.GA17229@nevyn.them.org> To: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Is stub support for the 's' packet optional or required? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00313.txt.bz2 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. Kevin