Single stepping and threads

[Daniel Jacobowitz <drow@false.org>]

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?

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?

-- 
Daniel Jacobowitz
CodeSourcery