Red Hat ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE, Manual

Page: 42 / 410

32 Chapter 6. Running Programs Under gdb
1 system thread 27905 0x7b003498 in _brk () \
from /usr/lib/libc.2
thread
threadno
Make thread number
threadno
the current thread. The command argument
threadno
is the
internal gdb thread number, as shown in the first field of the
info threads
display. gdb re-
sponds by displaying the system identifier of the thread you selected, and its current stack frame
summary:
(gdb) thread 2
[Switching to process 35 thread 23]
0x34e5 in sigpause ()
As with the
[New ...]
message, the form of the text after
Switching to
depends on your
system’s conventions for identifying threads.
thread apply [
threadno
] [
all
]
args
The
thread apply
command allows you to apply a command to one or more threads. Spec-
ify the numbers of the threads that you want affected with the command argument
threadno
.
threadno
is the internal gdb thread number, as shown in the first field of the
info threads
display. To apply a command to all threads, use
thread apply all args
.
Whenever gdb stops your program, due to a breakpoint or a signal, it automatically selects the thread
where that breakpoint or signal happened. gdb alerts you to the context switch with a message of the
form
[Switching to
systag
]
to identify the thread.
Refer to Section 7.4 Stopping and starting multi-thread programs for more information about how
gdb behaves when you stop and start programs with multiple threads.
Refer to Section 7.1.2
Setting watchpoints , for information about watchpoints in programs with mul-
tiple threads.
6.10. Debugging programs with multiple processes
On most systems, gdb has no special support for debugging programs which create additional pro-
cesses using the
fork
function. When a program forks, gdb will continue to debug the parent process
and the child process will run unimpeded. If you have set a breakpoint in any code which the child
then executes, the child will get a
SIGTRAP
signal which (unless it catches the signal) will cause it to
terminate.
However, if you want to debug the child process there is a workaround which isn’t too painful. Put
a call to
sleep
in the code which the child process executes after the fork. It may be useful to sleep
only if a certain environment variable is set, or a certain file exists, so that the delay need not occur
when you don’t want to run gdb on the child. While the child is sleeping, use the
ps
program to get
its process ID. Then tell gdb (a new invocation of gdb if you are also debugging the parent process)
to attach to the child process (refer to Section 6.7 Debugging an already-running process ). From that
point on you can debug the child process just like any other process which you attached to.
On HP-UX (11.x and later only?), gdb provides support for debugging programs that create additional
processes using the
fork
or
vfork
function.
By default, when a program forks, gdb will continue to debug the parent process and the child process
will run unimpeded.
If you want to follow the child process instead of the parent process, use the command
set
follow-fork-mode
.