This is the mail archive of the
mailing list for the GDB project.
Single stepping and threads
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb at sourceware dot org
- Date: Wed, 29 Nov 2006 00:29:42 -0500
- Subject: Single stepping and threads
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
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
- "step" acts like "next" when stepping over a function without debug
info. Should we honor "set scheduler-locking step" when doing