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: "thread", "thread apply" and "step" ?

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

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