Re: "thread", "thread apply" and "step" ?

[Vladimir Prus <vladimir@codesourcery.com>]

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