info filesshows your active targets.) The command takes as argument a process ID. The usual way to find out the process-id of a Unix process is with the
psutility, or with the `jobs -l' shell command.
attachdoes not repeat if you press RET a second time after executing the command.
attach, your program must be running in an environment
which supports processes; for example,
attach does not work for
programs on bare-board targets that lack an operating system. You must
also have permission to send the process a signal.
When you use
attach, the debugger finds the program running in
the process first by looking in the current working directory, then (if
the program is not found) by using the source file search path
(see section Specifying source directories). You can also use
file command to load the program. See section Commands to specify files.
The first thing GDB does after arranging to debug the specified
process is to stop it. You can examine and modify an attached process
with all the GDB commands that are ordinarily available when
you start processes with
run. You can insert breakpoints; you
can step and continue; you can modify storage. If you would rather the
process continue running, you may use the
continue command after
attaching GDB to the process.
detachcommand to release it from GDB control. Detaching the process continues its execution. After the
detachcommand, that process and GDB become completely independent once more, and you are ready to
attachanother process or start one with
detachdoes 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
confirm command (see section Optional warnings and messages).
Go to the first, previous, next, last section, table of contents.