From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7559 invoked by alias); 2 Sep 2011 16:45:40 -0000 Received: (qmail 7548 invoked by uid 22791); 2 Sep 2011 16:45:38 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Sep 2011 16:45:15 +0000 Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p82GjDZg021011 for ; Fri, 2 Sep 2011 09:45:13 -0700 Received: from gyd5 (gyd5.prod.google.com [10.243.49.197]) by hpaq6.eem.corp.google.com with ESMTP id p82Gj7wY020708 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Sep 2011 09:45:12 -0700 Received: by gyd5 with SMTP id 5so2364786gyd.29 for ; Fri, 02 Sep 2011 09:45:11 -0700 (PDT) Received: by 10.90.138.10 with SMTP id l10mr1015378agd.126.1314981911632; Fri, 02 Sep 2011 09:45:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.138.10 with SMTP id l10mr1015366agd.126.1314981911353; Fri, 02 Sep 2011 09:45:11 -0700 (PDT) Received: by 10.90.84.9 with HTTP; Fri, 2 Sep 2011 09:45:11 -0700 (PDT) In-Reply-To: <201108301621.55098.pedro@codesourcery.com> References: <20110830014851.78030246131@ruffy.mtv.corp.google.com> <20110830142115.GA2650@host1.jankratochvil.net> <201108301621.55098.pedro@codesourcery.com> Date: Fri, 02 Sep 2011 16:48:00 -0000 Message-ID: Subject: Re: [RFC] stept, nextt, finisht, untilt, continuet From: Doug Evans To: Pedro Alves Cc: gdb-patches@sourceware.org, Jan Kratochvil , pfee@talk21.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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-09/txt/msg00035.txt.bz2 On Tue, Aug 30, 2011 at 8:21 AM, Pedro Alves wrote: > 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 invente= d more >> > because `set scheduler-locking step' is not default+working. =A0I gues= s such >> > idea would not arise at all otherwise. =A0Any new configuration option= s and/or >> > more commands are bad when the same functionality can be reached other= wise. >> >> 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! =A0Blech. >> 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. =A0Working 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. [responding per suggestion from irc] Regardless of the ultimate syntax, I'll still find use for "st" and "nt" (step/next just the current thread). [possibly the others too, but the frequency is less that having to type something more than that probably won't be annoying] [And unless the ultimate syntax is effectively that trivial of course.]