Re: Single stepping and threads

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

On Tue, 2006-11-28 at 21:59 -0800, Joel Brobecker wrote:
> > The default is "off".  Should it be "step" instead?
> 
> I am not sure. On the one hand, I personally think that the current
> behavior makes it harder to debug the program. I've been fustrated
> a few times in the past when my next/step command got interrupted
> and I found myself in another thread -> I kept using breakpoints
> to do what I needed to do.
> 
> On the other hand, this has been the default behavior for so long
> that it's something you expect...  I don't know how much this will
> impact the users. At AdaCore, I don't remember receiving any report
> of that sort from our users, and tasking in Ada is something that's
> commonly used.
> 
> The other argument against is that the debugger is supposed to be
> transparent to the execution. This is not 100% true, but I think
> we are very very close to it. Except maybe with certain thread
> layers? Not sure, this is not my area of expertise, to say the
> least. But for sure changing the setting to either "on" or "step"
> will cause the debugger to affect the scheduling of the inferior.

That's correct.  GDB is unavoidably intrusive when it comes to
thread scheduling.  The default behavior ("off"), is the least
intrusive, and somewhat randomly, unpredictably intrusive.

"Step" would be more intrusive, and non-randomly so.  It will
cause the "current" thread to be strongly preferred, and other
threads will probably starve.

"On" is the most intrusive -- no other threads can run, and
if there are any synchronization issues, the program will 
eventually deadlock.


> 
> So, to summarize, I'm somewhat in favor. I'll poll my team-mates
> and see if they have any interesting ideas to share on the subject.
> 
> > 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 :-)
> 
> I agree with that. If we decide to make that change, and that hides
> issues as a result, then these particular issues become less important,
> and you can spend the time working on other things that you like.
> 
> > A related issue is the tendency of "step" to let other threads run even
> > in "set scheduler-locking step".  For instance:
> [...]
> >   - "step" acts like "next" when stepping over a function without debug
> >     info.  Should we honor "set scheduler-locking step" when doing
> >     this?
> 
> I would say yes. A step should be a few instructions, while stepping
> over a call is potentially a much larger number of instructions.
> As a result, stepping over without letting the other threads go would
> more likely cause a lock.
>