Re: [RFC] stept, nextt, finisht, untilt, continuet

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 30 August 2011 16:08:52, Doug Evans wrote:
> On Tue, Aug 30, 2011 at 7:21 AM, Jan Kratochvil
> <jan.kratochvil@redhat.com> 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