From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37261 invoked by alias); 21 Oct 2015 18:10:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 37252 invoked by uid 89); 21 Oct 2015 18:10:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 21 Oct 2015 18:10:54 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 87C2791341 for ; Wed, 21 Oct 2015 18:10:53 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-96.ams2.redhat.com [10.36.116.96]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9LIAoO1020979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Oct 2015 14:10:52 -0400 Date: Thu, 22 Oct 2015 07:21:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/4] Make "set scheduler-locking step" depend on user intention, only Message-ID: <20151021181049.GA16596@host1.jankratochvil.net> References: <1426084798-1032-1-git-send-email-palves@redhat.com> <1426084798-1032-4-git-send-email-palves@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426084798-1032-4-git-send-email-palves@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00425.txt.bz2 On Wed, 11 Mar 2015 15:39:57 +0100, Pedro Alves wrote: > Currently, "set scheduler-locking step" is a bit odd. The manual > documents it as being optimized for stepping, so that focus of > debugging does not change unexpectedly, but then it says that > sometimes other threads may run, and thus focus may indeed change > unexpectedly... A user can then be excused to get confused and wonder > why does GDB behave like this. > > I don't think a user should have to know about details of how "next" > or whatever other run control command is implemented internally to > understand when does the "scheduler-locking step" setting take effect. > > This patch completes a transition that the code has been moving > towards for a while. It makes "set scheduler-locking step" hold > threads depending on whether the _command_ the user entered was a > stepping command [step/stepi/next/nexti], or not. After some internal discussion making a note this can be considered a regression from the user point of view. LLDB by default locks the current thread if it keeps stepping inside the current frame; but if it needs to run some other code it will run it with all threads enabled. This mostly matches what GDB did for the "set scheduler-locking step" mode - AFAIK GDB ran all the threads for the parts which it was "continuing". Which is also most convenient to be the default mode if one does not think much about how one wants to step this time. Jan