Debugging with GDB Manual HP WDB v6.3 (5900-2180, August 2012)

detached. After the detach command, that process and GDB become completely
independent once more, and you are ready to attach another process or start one
with run. detach does not repeat if you press RET again after executing the command.
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 “Optional warnings and
messages” (page 227)).
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 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.
4.8 Killing the child process 35