From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21882 invoked by alias); 30 Aug 2011 15:22:14 -0000 Received: (qmail 21862 invoked by uid 22791); 30 Aug 2011 15:22:12 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 15:21:58 +0000 Received: (qmail 24404 invoked from network); 30 Aug 2011 15:21:57 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Aug 2011 15:21:57 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] stept, nextt, finisht, untilt, continuet Date: Tue, 30 Aug 2011 15:22:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) Cc: Doug Evans , Jan Kratochvil , pfee@talk21.com References: <20110830014851.78030246131@ruffy.mtv.corp.google.com> <20110830142115.GA2650@host1.jankratochvil.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108301621.55098.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2011-08/txt/msg00608.txt.bz2 On Tuesday 30 August 2011 16:08:52, Doug Evans wrote: > On Tue, Aug 30, 2011 at 7:21 AM, Jan Kratochvil > wrote: > > My original post was that I believe the new `*t' commands were invented more > > because `set scheduler-locking step' is not default+working. I guess such > > idea would not arise at all otherwise. Any new configuration options and/or > > more commands are bad when the same functionality can be reached otherwise. > > My patch is partially because "set scheduler-locking step" doesn't > apply to next, > but it also doesn't apply to other commands. > > *And* at least as importantly, if not more so, I don't always want > "set scheduler-locking step", > and having to remember to switch global state back and forth is > extremely clumsy! Blech. > In my sessions the setting of scheduler-locking is far more dynamic, a > global state setting is the wrong solution. > > I kinda like adding a new option to step,next,etc., but writing > wrappers in python doesn't add new commands to gdb proper. > One of the reasons we have python. I'm currently working towards adding (run control) ptset/itset support to gdb. Working on instructure still (I can run all-stop on top of a target running in non-stop mode now), and the final syntax will obviously need discussion, but I think we could come up with syntax for this within that framework. -- Pedro Alves