Debugging with GDB Manual The GNU Source-Level Debugger (769148-001, March 2014)

NOTE: When GDB attaches to a running program you may get a message saying "Attaching
to process #nnnnn failed."
The most likely cause for this message is that you have attached to a process that was started
across an NFS mount. Versions of the HP-UX kernel before 11.x have a restriction that prevents a
debugger from attaching to a process started from an NFS mount, unless the mount was made
non-interruptible with the -nointr flag, see mount(1).
Killing the child process
Following command is used to kill the child process:
kill Kill the child process in which your program is running under GDB.
The kill 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).
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.
32 Running Programs Under GDB