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

[Doug Evans <dje at google dot com>]

On Tue, Aug 30, 2011 at 8:21 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> 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.

[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.]