From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11498 invoked by alias); 10 Jan 2006 21:20:54 -0000 Received: (qmail 11488 invoked by uid 22791); 10 Jan 2006 21:20:53 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jan 2006 21:20:50 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0ALKnVh030255 for ; Tue, 10 Jan 2006 16:20:49 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0ALKm129117; Tue, 10 Jan 2006 16:20:48 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0ALKg78004499; Tue, 10 Jan 2006 16:20:47 -0500 Message-ID: <43C424D7.5040704@redhat.com> Date: Tue, 10 Jan 2006 21:20:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Amit Kale CC: GDB patches Subject: Re: [PATCH] preventing resuming of threads in gdbserver References: <200601101805.31069.amitkale@linsyssoft.com> In-Reply-To: <200601101805.31069.amitkale@linsyssoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00102.txt.bz2 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. 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));