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

For example,
((gdb)) info threads
* 3 system thread 26607 worker (wptr=0x7b09c318
"@") \
at quicksort.c:137
2 system thread 26606 0x7b0030d8 in __ksleep ()
\
from /usr/lib/libc.2
1 system thread 27905 0x7b003498 in _brk () \
from /usr/lib/libc.2
thread threadno Make thread number threadno the current thread. The
command argument threadno is the internal GDB thread
number, as shown in the first field of the 'info threads'
display. GDB responds by displaying the system identifier
of the thread you selected, and its current stack frame
summary:
((gdb)) thread 2
[Switching to thread 2 (system thread 26594)]
0x34e5 in sigpause ()
As with the '[New ...]' message, the form of the text after
'Switching to' depends on your system's conventions
for identifying threads.
thread apply [threadno]
[all] args
The thread apply command allows you to apply a
command to one or more threads. Specify the numbers of
the threads that you want affected with the command
argument threadno. threadno is the internal GDB thread
number, as shown in the first field of the 'info threads'
display. To apply a command to all threads, use thread
apply all args.
Whenever GDB stops your program, due to a breakpoint or a signal, it automatically selects the
thread where that breakpoint or signal happened. GDB alerts you to the context switch with a
message of the form '[Switching to systag]' to identify the thread.
See “Stopping and starting multi-thread programs” (page 52), for more information about how
GDB behaves when you stop and start programs with multiple threads.
See “Killing the child process” (page 35), for information about watchpoints in programs with
multiple threads.
NOTE: On HP-UX 11.x, debugging a multi-thread process can cause a deadlock if the process
is waiting for an NFS-server response. A thread can be stopped while asleep in this state, and
NFS holds a lock on the rnode while asleep.
To prevent the thread from being interrupted while holding the rnode lock, make the NFS mount
non-interruptible with the '-nointr' flag. See mount(1).
4.10 Debugging programs with multiple processes
On most systems, GDB has no special support for debugging programs which create additional
processes using the fork function. When a program forks, GDB will continue to debug the parent
process and the child process will run unimpeded. If you have set a breakpoint in any code which
the child then executes, the child will get a SIGTRAP signal which (unless it catches the signal)
will cause it to terminate.
However, if you want to debug the child process there is a workaround which isn't too painful.
Put a call to sleep in the code which the child process executes after the fork. It may be useful to
sleep only if a certain environment variable is set, or a certain file exists, so that the delay need
4.10 Debugging programs with multiple processes 37