"thread", "thread apply" and "step" ?

["Rich Wagner" <richwagner at tilera dot com>]

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

My experiments have shown that "thread A" has no effect on the
subsequent step, i.e. both threads suspend again when *B* hits its
end-of-step boundary.  This seems to me to be a "gdb" bug: if "thread A"
followed by "bt" shows me A's backtrace, then why is "step" different?

Furthermote, if - after B hits a breakpoint - I type:

            thread apply A step

then it's *still* B that actually does the stepping.


I'm using "gdb --version":

            GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)

Am I seeing a GDB bug, or am I seeing the correct GDB behavior?  If the
latter, is it possible at all to get what I want, i.e. after B hits a
breakpoint, arrange for A to step?

Thanks in advance,
Rich


P.S.  Where I work, we also use a customized version of gdb where we
provide our own RSP interpreter, because the customized version is used
for remote debugging.  Would the introduction of RSP change things as
they relate to threads and stepping?  I'm assuming the "official"
GDB-spec-based answers would necessarily apply to an RSP-based debug
session, but I mention RSP in case it affects things.

 

----------------------------

Rich Wagner, Senior Engineer
Tilera Corporation

----------------------------