Red Hat ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE, Руководство пользователя

Страница: 61 / 410

Chapter 7. Stopping and Continuing 51
nopass
ignore
{No value for ‘ listitem>GDBN’} should not allow your program to see this signal.
nopass
and
ignore
are synonyms.
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.
The default is set to
nostop
,
noprint
,
pass
for non-erroneous signals such as
SIGALRM
,
SIGWINCH
and
SIGCHLD
, and to
stop
,
print
,
pass
for the erroneous signals.
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
. Refer to Section 16.3 Giving your program a signal .
7.4. Stopping and starting multi-thread programs
When your program has multiple threads (refer to Section 6.9 Debugging programs with multiple
threads ), 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 breakpoint 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 cur-
rent 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.
On some OSes, you can lock the OS scheduler and thus allow only a single thread to run.