Debugging with GDB (February 2008)

28 Debugging with GDB
If you exit GDB or use the run command while you have an attached process, you kill
that process. By default, GDB asks for confirmation if you try to do either of these things;
you can control whether or not you need to confirm by using the set confirm command
(see Section 17.6 [Optional warnings and messages], page 252).
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).
4.8 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).
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 configura-
tion 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: