Debugging with GDB Manual (5900-1473; WDB 6.2; January 2011)

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).
4.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 private memory.
GDB provides these facilities for debugging multi-thread programs:
• automatic notification of new threads
• thread-specific breakpoints
WARNING! These facilities are not yet available on every GDB configuration where
the operating system supports 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.
Following commands are used to debug multi-threaded programs:
• '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
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.
4.9 Debugging programs with multiple threads 41