Debugging with GDB (February 2008)

48 Debugging with GDB
When a signal stops your program, the signal is not visible to the program until you
continue. Your program sees the signal then, if pass is in effect for the signal in question
at that time. In other words, after GDB reports a signal, you can use the handle command
with pass or nopass to control whether your program sees that signal when you continue.
You can also use the signal command to prevent your program from seeing a signal, or
cause it to see a signal it normally would not see, or to give it any signal at any time. For
example, if your program stopped due to some sort of memory reference error, you might
store correct values into the erroneous variables and continue, hoping to see more execution;
but your program would probably terminate immediately as a result of the fatal signal once
it saw the signal. To prevent this, you can continue with ‘signal 0’. See
Section 11.3
[Giving your program a signal], page 99.
5.4 Stopping and starting multi-thread programs
When your program has multiple threads (see Section 4.9 [Debugging programs with
multiple threads], page 28), you can choose whether to set breakpoints on all threads, or
on a particular thread.
break linespec thread threadno
break linespec thread threadno if ...
linespec specifies source lines; there are several ways of writing them, but the
effect is always to specify some source line.
Use the qualifier ‘thread threadno ’ with a breakpoint command to specify
that you only want GDB to stop the program when a particular thread reaches
this breakpoint. threadno is one of the numeric thread identifiers assigned by
GDB, shown in the first column of the ‘info threads’ display.
If you do not specify ‘thread threadno ’ when you set a breakpoint, the break-
point applies to all threads of your program.
You can use the thread qualifier on conditional breakpoints as well; in this
case, place ‘thread threadno ’ before the breakpoint condition, like this:
((gdb)) break frik.c:13 thread 28 if bartab > lim
Whenever your program stops under GDB for any reason, all threads of execution stop,
not just the current thread. This allows you to examine the overall state of the program,
including switching between threads, without worrying that things may change underfoot.
Conversely, whenever you restart the program, all threads start executing. This is true
even when single-stepping with commands like step or next.
In particular, GDB cannot single-step all threads in lockstep. Since thread scheduling
is up to your debugging target’s operating system (not controlled by GDB), other threads
may execute more than one statement while the current thread completes a single step.
Moreover, in general other threads stop in the middle of a statement, rather than at a clean
statement boundary, when the program stops.
You might even find your program stopped in another thread after continuing or even
single-stepping. This happens whenever some other thread runs into a breakpoint, a signal,
or an exception before the first thread completes whatever you requested.