From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14774 invoked by alias); 25 Aug 2004 16:03:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14759 invoked from network); 25 Aug 2004 16:03:16 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 25 Aug 2004 16:03:16 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1C00F2-0008C3-B1; Wed, 25 Aug 2004 12:03:16 -0400 Date: Wed, 25 Aug 2004 16:03:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: schedlock.exp questions Message-ID: <20040825160315.GA31412@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <412B55E1.7040803@axis.com> <20040824145502.GA26280@nevyn.them.org> <412CABED.10108@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412CABED.10108@axis.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00695.txt.bz2 On Wed, Aug 25, 2004 at 05:10:37PM +0200, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > >No. The request was "single-step this thread, but allow other threads > >to run while you do it". Other threads might report a breakpoint (not > >possible in this testcase), but they shouldn't report a single-step > >trap - they shouldn't singlestep. > > Thanks for clarifying. Would you mind explaining the "not possible in > this testcase" part? I do get spurious SIGTRAPs for the other threads > from the "break 41 if arg != 5" breakpoint, reported as SIGTRAP (instead > of as breakpoint hits). What should happen is: - we stop all threads - we see that a thread has hit this breakpoint - we check that this breakpoint should stop - it shouldn't! condition is false! - we singlestep this thread past the breakpoint - we resume This is a twisty and nasty part of infrun. It is full of bugs and things that need to be rearchitected. So it's quite likely it doesn't work right. Is this native or remote (gdbserver based)? I have some patches which make it substantially more reliable on slow native targets but I haven't had enough time to test them properly. They shouldn't affect remote though. -- Daniel Jacobowitz