"thread", "thread apply" and "step" ?
Rich Wagner
richwagner@tilera.com
Tue Aug 5 20:11:00 GMT 2008
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
----------------------------
More information about the Gdb
mailing list