From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23724 invoked by alias); 11 Jan 2006 07:35:51 -0000 Received: (qmail 23712 invoked by uid 22791); 11 Jan 2006 07:35:49 -0000 X-Spam-Check-By: sourceware.org Received: from svr68.ehostpros.com (HELO svr68.ehostpros.com) (67.15.48.48) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jan 2006 07:35:46 +0000 Received: from [59.95.1.118] (helo=titan.linsyssoft.com) by svr68.ehostpros.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EwaW5-00023v-T6; Tue, 10 Jan 2006 23:35:35 -0800 Received: from pythagoras.linsyssoft.com (pythagoras [192.168.1.3] (may be forged)) by titan.linsyssoft.com (8.13.1/8.13.1) with ESMTP id k0B7MKxh012508; Wed, 11 Jan 2006 12:52:20 +0530 From: Amit Kale To: Daniel Jacobowitz Subject: Re: [PATCH] preventing resuming of threads in gdbserver Date: Wed, 11 Jan 2006 07:35:00 -0000 User-Agent: KMail/1.8 Cc: Michael Snyder , GDB patches References: <200601101805.31069.amitkale@linsyssoft.com> <43C424D7.5040704@redhat.com> <20060110213945.GA1535@nevyn.them.org> In-Reply-To: <20060110213945.GA1535@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601111305.34909.amitkale@linsyssoft.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00113.txt.bz2 On Wednesday 11 Jan 2006 3:09 am, Daniel Jacobowitz wrote: > On Tue, Jan 10, 2006 at 01:19:19PM -0800, Michael Snyder wrote: > > Amit Kale wrote: > > >Hi, > > > > > >gdb lets other threads continue execution during single stepping when > > >doing a single step in remote mode. This behavior causes thread switches > > >during step or next commands. Native mode behavior is opposite of it. > > >Attached patch changes it and makes it similar to native mode. > > > > Actually, letting other threads continue during single stepping > > is the norm. It happens on almost all multi-thread gdb targets. > > Michael's right. It sometimes does not obviously manifest on native > targets, depending on the implementation of the native system's > scheduler. Yes I am convinced that it's just my setup that never shows a thread switch during a single step. It might occur in some setup. > > On the other hand, there is a user-setable mode variable > > called "scheduler-locking", which is meant to have the exact > > effect you are looking for. If you wanted to re-do your patch > > so that it made this change conditionally, under the control of > > that variable, it might be more acceptable. > > Take a look at the implementation of scheduler-locking; this should > already work for gdbserver - and there's a testcase for it! Right. schduler-locking works now. Thanks. -Amit