Debugging Programs With Multiple Threads - Red Hat ENTERPRISE LINUX 3 - DEBUGGING WITH GDB Manual

Debugging with gdb
Hide thumbs Also See for ENTERPRISE LINUX 3 - DEBUGGING WITH GDB:
Table of Contents

Advertisement

30
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
outside the debugger.
The
command is also useful if you wish to recompile and relink your program, since on many
kill
systems it is impossible to modify an executable file while it is running in a process. In this case, when
you next type
, gdb notices that the file has changed, and reads the symbol table again (while trying
run
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 inquire about existing threads
info threads
thread apply [
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
like this:
(gdb) info threads
(gdb) thread 1
Thread ID 1 not known.
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
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
, with no further qualifier.
process 368
kill
, a command to switch among threads
] [
]
threadno
all
args
Use the "info threads" command to
[New
Chapter 6. Running Programs Under gdb
command in this situation to permit running your program
, a command to apply a command to a list of threads
, and always rejects the
info threads
.
is a thread identifier whose form varies
]
systag
systag
thread
is simply something like
systag
command,

Advertisement

Table of Contents
loading

Table of Contents