Re: Single stepping and threads

[Michael Snyder <Michael.Snyder@palmsource.com>]

On Wed, 2006-11-29 at 00:29 -0500, Daniel Jacobowitz wrote:
> Ulrich's message earlier reminded me of something I've been meaning to
> discuss for a while.  This isn't specific to software single stepping,
> but to single step in general for threaded programs.
> 
> We have a knob "set scheduler-locking".  It offers three values:
> 
> Set mode for locking scheduler during execution.
> off  == no locking (threads may preempt at any time)
> on   == full locking (no thread except the current thread may run)
> step == scheduler locked during every single-step operation.
>         In this mode, no other thread may run during a step command.
>         Other threads may run while stepping over a function call
>         ('next').
> 
> The default is "off".  Should it be "step" instead?  The example I used
> to use whenever someone asked me about this was single stepping through
> something like a barrier or mutex; if other threads don't run, you
> won't advance, because no other thread will have a chance to release
> the lock.  That much is true.  But it seems like a reasonable thing to
> document and reference "set scheduler-locking".  And having threads
> run during single stepping has surprised a lot of users who've asked
> me about the current behavior.
> 
> What do you all think?

I implemented "set scheduler-locking", at user request.

The behavior that the users were requesting is "step".

I left the default at "off", because that was gdb's 
original behavior, and I didn't want to change it 
out from under people without notice.

It may very well be time to change the default.

> 
> One reason I've procrastinated bringing this up is that set
> scheduler-locking off, the current default, has a lot more nasty
> corner cases that I've meant to look into; if step becomes the default,
> I suspect more of those will linger unfixed.  But users won't encounter
> them as often, which is much like fixing them :-)
> 
> A related issue is the tendency of "step" to let other threads run even
> in "set scheduler-locking step".  For instance:
> 
>   - We use a breakpoint to skip the prologue of a function when we step
>     into it.  This could either be implemented with a stepping range
>     instead, or else we could continue to use the breakpoint but honor
>     the scheduler locking mode anyway, but the current behavior is
>     silly.
> 
>   - "step" acts like "next" when stepping over a function without debug
>     info.  Should we honor "set scheduler-locking step" when doing
>     this?
>