This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Single stepping and threads

> 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.

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.


PS: My understanding is that not all systems support the running
    of an individual thread instead of the entire program. Is that
    right? Or do all systems support this feature?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]