From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17190 invoked by alias); 11 Jan 2006 07:17:47 -0000 Received: (qmail 17181 invoked by uid 22791); 11 Jan 2006 07:17:47 -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:17:45 +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 1EwaEe-0001eZ-Sq; Tue, 10 Jan 2006 23:17:34 -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 k0B74HGL012289; Wed, 11 Jan 2006 12:34:17 +0530 From: Amit Kale To: Michael Snyder Subject: Re: [PATCH] preventing resuming of threads in gdbserver Date: Wed, 11 Jan 2006 07:17:00 -0000 User-Agent: KMail/1.8 Cc: GDB patches References: <200601101805.31069.amitkale@linsyssoft.com> <43C424D7.5040704@redhat.com> In-Reply-To: <43C424D7.5040704@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601111247.32131.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/msg00112.txt.bz2 On Wednesday 11 Jan 2006 2:49 am, 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. > Indeed, if you don't allow it to happen, you're risking deadlock, > and certainly changing the program behavior. Thanks. I wasn't aware that this was by design. Native gdb doesn't seem to switch threads during a "next", which made me think that it's the other way around. Digging further, following code in resume() does handle scheduler_mode correctly. if ((scheduler_mode == schedlock_on) || (scheduler_mode == schedlock_step && (step || singlestep_breakpoints_inserted_p))) { /* User-settable 'scheduler' mode requires solo thread resume. */ resume_ptid = inferior_ptid; } -Amit > > 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. > > > ------------------------------------------------------------------------ > > > > Index: gdb-cvs/gdb/remote.c > > =================================================================== > > --- gdb-cvs.orig/gdb/remote.c 2006-01-03 11:24:35.000000000 +0530 > > +++ gdb-cvs/gdb/remote.c 2006-01-10 18:00:05.000000000 +0530 > > @@ -2519,10 +2519,10 @@ > > { > > /* Resume all threads, with preference for INFERIOR_PTID. */ > > if (step && siggnal != TARGET_SIGNAL_0) > > - outbuf = xstrprintf ("vCont;S%02x:%x;c", siggnal, > > + outbuf = xstrprintf ("vCont;S%02x:%x", siggnal, > > PIDGET (inferior_ptid)); > > else if (step) > > - outbuf = xstrprintf ("vCont;s:%x;c", PIDGET (inferior_ptid)); > > + outbuf = xstrprintf ("vCont;s:%x", PIDGET (inferior_ptid)); > > else if (siggnal != TARGET_SIGNAL_0) > > outbuf = xstrprintf ("vCont;C%02x:%x;c", siggnal, > > PIDGET (inferior_ptid));