From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24688 invoked by alias); 10 Jan 2006 21:39:56 -0000 Received: (qmail 24680 invoked by uid 22791); 10 Jan 2006 21:39:53 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 10 Jan 2006 21:39:50 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EwRDW-0000QZ-5X; Tue, 10 Jan 2006 16:39:46 -0500 Date: Tue, 10 Jan 2006 21:39:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: Amit Kale , GDB patches Subject: Re: [PATCH] preventing resuming of threads in gdbserver Message-ID: <20060110213945.GA1535@nevyn.them.org> Mail-Followup-To: Michael Snyder , Amit Kale , GDB patches References: <200601101805.31069.amitkale@linsyssoft.com> <43C424D7.5040704@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C424D7.5040704@redhat.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00103.txt.bz2 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. > Indeed, if you don't allow it to happen, you're risking deadlock, > and certainly changing the program behavior. > > Moreover, a patch that changes the behavior of *all* remote targets > is going to be challenging to get approved. > > > > 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! -- Daniel Jacobowitz CodeSourcery