Red Hat ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE, Manual

Page: 40 / 410

30 Chapter 6. Running Programs Under gdb
This command is useful if you wish to debug a core dump instead of a running process. gdb ignores
any core dump file while your program is running.
On some operating systems, a program cannot be executed outside gdb while you have breakpoints
set on it inside gdb. You can use the
kill
command in this situation to permit running your program
outside the debugger.
The
kill
command is also useful if you wish to recompile and relink your program, since on many
systems it is impossible to modify an executable file while it is running in a process. In this case, when
you next type
run
, gdb notices that the file has changed, and reads the symbol table again (while trying
to preserve your current breakpoint settings).
6.9. Debugging programs with multiple threads
In some operating systems, such as HP-UX and Solaris, a single program may have more than one
thread of execution. The precise semantics of threads differ from one operating system to another, but
in general the threads of a single program are akin to multiple processes--except that they share one
address space (that is, they can all examine and modify the same variables). On the other hand, each
thread has its own registers and execution stack, and perhaps private memory.
gdb provides these facilities for debugging multi-thread programs:
•
automatic notification of new threads
•
thread
threadno
, a command to switch among threads
• info threads
, a command to inquire about existing threads
•
thread apply [
threadno
] [
all
]
args
, a command to apply a command to a list of threads
•
thread-specific breakpoints
Warning: These facilities are not yet available on every gdb configuration where the operating system sup-
ports threads. If your gdb does not support threads, these commands have no effect. For example, a system
without thread support shows no output from
info threads
, and always rejects the
thread
command,
like this:
(gdb) info threads
(gdb) thread 1
Thread ID 1 not known.
Use the "info threads" command to
see the IDs of currently known threads.
The gdb thread debugging facility allows you to observe all threads while your program runs--but
whenever gdb takes control, one thread in particular is always the focus of debugging. This thread is
called the current thread . Debugging commands show program information from the perspective of
the current thread.
Whenever gdb detects a new thread in your program, it displays the target system’s identification for
the thread with a message in the form
[New
systag
]
.
systag
is a thread identifier whose form varies
depending on the particular system. For example, on LynxOS, you might see
[New process 35 thread 27]
when gdb notices a new thread. In contrast, on an SGI system, the
systag
is simply something like
process 368
, with no further qualifier.