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

not occur when you do not want to run GDB on the child. While the child is sleeping, use the ps
program to get its process ID. Then tell GDB (a new invocation of GDB if you are also debugging
the parent process) to attach to the child process (see “Debugging a Running Process” (page 34)).
From that point on you can debug the child process just like any other process which you attached
to.
On HP-UX (11.x and later only), GDB provides support for debugging programs that create
additional processes using the fork or vfork function.
By default, when a program forks, GDB will continue to debug the parent process and the child
process will run unimpeded.
If you want to follow the child process instead of the parent process, use the command set
follow-fork-mode.
set follow-fork-mode mode Set the debugger response to a program call of fork or
vfork. A call to fork or vfork creates a new process.
The mode can be:
parent The original process is debugged after a fork.
The child process runs unimpeded. This is the
default.
child The new process is debugged after a fork. The
parent process runs unimpeded.
show follow-fork-mode Display the current debugger response to a fork or vfork
call.
If you ask to debug a child process and a vfork is followed by an exec, GDB executes the new
target up to the first breakpoint in the new target. If you have a breakpoint set on main in your
original program, the breakpoint will also be set on the child process's main.
When a child process is spawned by vfork, you cannot debug the child or parent until an exec
call completes.
If you issue a run command to GDB after an exec call executes, the new target restarts. To restart
the parent process, use the file command with the parent executable name as its argument.
You can use the catch command to make GDB stop whenever a fork, vfork, or exec call is
made. See “Setting catchpoints” (page 42).
38 Running Programs Under GDB