Re: [PATCH 3/4] Make "set scheduler-locking step" depend on user intention, only

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 11 Mar 2015 15:39:57 +0100, Pedro Alves wrote:
> 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.
> 
> This patch completes a transition that the code has been moving
> towards for a while.  It 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.

After some internal discussion making a note this can be considered a
regression from the user point of view.

LLDB by default locks the current thread if it keeps stepping inside the
current frame; but if it needs to run some other code it will run it with all
threads enabled.

This mostly matches what GDB did for the "set scheduler-locking step" mode -
AFAIK GDB ran all the threads for the parts which it was "continuing".
Which is also most convenient to be the default mode if one does not think much
about how one wants to step this time.


Jan