This is the mail archive of the
mailing list for the GDB project.
Re: Single stepping and threads
- From: Michael Snyder <Michael dot Snyder at palmsource dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org
- Date: Thu, 30 Nov 2006 15:22:32 -0800
- Subject: Re: Single stepping and threads
- References: <20061129052942.GA16029@nevyn.them.org>
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
> 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
> - "step" acts like "next" when stepping over a function without debug
> info. Should we honor "set scheduler-locking step" when doing