Tornado

7
Debugger
Internally, the debugger still gets control every time any thread encounters the
breakpoint; but if the thread ID is not the one you specified with the break
command, the debugger silently continues program execution without prompting
you.
! CAUTION: Because the thread ID for the system context is not constant, it is not
possible to set a breakpoint specific to system context. The only way to stop when
a breakpoint is encountered in system context is to use a non-task-specific
breakpoint.
7
Switching Threads Implicitly
Your program may not always suspend in the thread you expect. If any breakpoint
or other event (such as an exception) occurs while in system mode, in any thread,
the debugger gets control. Whenever the target system is stopped, the debugger
switches to the thread that was executing. If the new current thread is different
from the previous value, a message beginning “Switching to” shows what thread
suspended:
(gdb) thread 2
(gdb) cont
Continuing.
Interrupt...
Program received signal SIGINT, Interrupt.
[Switching to system +]
0x5b58 in wdbSuspendSystemHere ()
Whenever the debugger does not have control, you can interrupt the target system
by clicking on the interrupt button or by keying the interrupt character (usually
CTRL+C). This usually suspends the target in the system thread rather than in any
task.
When you step program execution (with any of the commands step, stepi, next,or
nexti, or the equivalent buttons or ), the target resumes execution where it
left off, in the thread marked with + in the info threads display. However, in the
course of stepping that thread, other threads may begin executing. Hence, the
debugger may stop in another thread before the stepping command completes,
due to an event in that other thread.
265