From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116767 invoked by alias); 11 Mar 2015 14:40:03 -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 116757 invoked by uid 89); 11 Mar 2015 14:40:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 11 Mar 2015 14:40:02 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BEdx1r010940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 11 Mar 2015 10:40:00 -0400 Received: from brno.lan (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BEdwDL006029 for ; Wed, 11 Mar 2015 10:39:59 -0400 From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 0/4] Make "set scheduler-locking step" depend on user intention, only Date: Wed, 11 Mar 2015 14:40:00 -0000 Message-Id: <1426084798-1032-1-git-send-email-palves@redhat.com> X-SW-Source: 2015-03/txt/msg00292.txt.bz2 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. Thus this series 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. More details in patch #3. The rest of the series is related groundwork and cleaning up. Tested on x86_64 Fedora 20, native and gdbserver. Pedro Alves (4): No longer handle negative 'step' in 'proceed' Make step_start_function be per thread Make "set scheduler-locking step" depend on user intention, only Remove 'step' parameters from 'proceed' and 'resume' gdb/breakpoint.c | 2 +- gdb/doc/gdb.texinfo | 5 +- gdb/gdbthread.h | 8 ++ gdb/infcall.c | 2 +- gdb/infcmd.c | 38 +++++---- gdb/infrun.c | 139 ++++++++++++++++---------------- gdb/infrun.h | 4 +- gdb/mi/mi-main.c | 2 +- gdb/testsuite/gdb.threads/schedlock.exp | 11 ++- gdb/windows-nat.c | 2 +- 10 files changed, 114 insertions(+), 99 deletions(-) -- 1.9.3