This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: "thread", "thread apply" and "step" ?
Michael Snyder wrote:
> On Tue, 2008-08-05 at 16:11 -0400, Rich Wagner wrote:
>> I haven't been able to find an "official" GDB spec which answers a
>> question I have, relating to threads and stepping, so...
>>
>>
>> Say your program has two threads, A and B, and that B most recently hit
>> a breakpoint.
>>
>> It's pretty clear (and my experiments have shown) that if you then
>> simply execute "step", then the step occurs in B. That is, both threads
>> resume execution, with both threads suspending again when B reaches the
>> "end-of-step" boundary. So far, so good...
>>
>> However, things become less clear, and non-intuitive, if after B hits a
>> breakpoint, and I then use:
>>
>> thread A
>> step
>
> The short answer is "don't do that".
>
> What I *wanted* to say is "you can't do that".
> The problem is, as you have discovered, you can --
> it just doesn't have the effect that you think it should.
>
> GDB's "thread" command will specify a thread to which
> subsequent state queries will apply (eg. "info register").
>
> But GDB does not exercise any control over the operating
> system's thread scheduling, therefore GDB has no control
> over which thread will actually run when you say "step"
> or "continue". You might think it should be the thread
> that you last selected -- but it won't. It will be the
> thread that the operating system chooses (generally the
> one that was most recently running).
Well, with scheduler locking on, it should be the thread that
is selected. More specifically, the call to target_resume should
be passed the ptid of the selected thread. For native linux, this
indeed has the effect of resuming the right thread. Further, in
non-stop mode scheduler locking is implicitly on, so:
-exec-continue --thread N
will always resume just thread N, without changing the state of any
other thread.
A target that is neither linux nor remote can, in theory, ignore the ptid
passed to target_resume. I don't know if such targets exist or not.
- Volodya