On Mon, 12 Oct 1998 16:04:09 -0400 Anukool Lakhina wrote:
> Does gdb allow me to trace the actions of a specific child process that has
> been forked? If so, how?
Yes it does. The manuals/user guides for gdb and all the gnu packages that I am
familiar with are distributed as texinfo files. Texinfo is also the name of the
program for processing the *.texi files into *.info for on-line browsing.
They contain hyper-links to related internal (within the set of gdb info files)
and external (nodes that belong to other programs/packages. nodes. HTML and
other document formats (text, PS, PCL, etc.) can be produced using TeX
utilities.
The nodes which cover your question follow. There is an extensive on-line help
facility through the gdb command "help".
Regards,
David Ross
[EMAIL PROTECTED]
Toad Technologies
"I'll be good! I will, I will !"
------------- Begin Included Info Nodes -------------
File: gdb.info, Node: Active Targets, Next: Target Commands, Up: Targets
Active targets
==============
There are three classes of targets: processes, core files, and
executable files. GDB can work concurrently on up to three active
targets, one in each class. This allows you to (for example) start a
process and inspect its activity without abandoning your work on a core
file.
For example, if you execute `gdb a.out', then the executable file
`a.out' is the only active target. If you designate a core file as
well--presumably from a prior run that crashed and coredumped--then GDB
has two active targets and uses them in tandem, looking first in the
corefile target, then in the executable file, to satisfy requests for
memory addresses. (Typically, these two classes of target are
complementary, since core files contain only a program's read-write
memory--variables and so on--plus machine status, while executable
files contain only the program text and initialized data.)
When you type `run', your executable file becomes an active process
target as well. When a process target is active, all GDB commands
requesting memory addresses refer to that target; addresses in an
active core file or executable file target are obscured while the
process target is active.
Use the `core-file' and `exec-file' commands to select a new core
file or executable target (*note Commands to specify files: Files.).
To specify as a target a process that is already running, use the
`attach' command (*note Debugging an already-running process: Attach.).
File: gdb.info, Node: Attach, Next: Kill Process, Prev: Input/Output, Up:
Running
Debugging an already-running process
====================================
`attach PROCESS-ID'
This command attaches to a running process--one that was started
outside GDB. (`info files' shows 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 `ps' utility, or with
the `jobs -l' shell command.
`attach' does not repeat if you press <RET> a second time after
executing the command.
To use `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 using `attach', you should first use the `file' command to
specify the program running in the process and load its symbol table.
*Note Commands to Specify Files: 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.
`detach'
When you have finished debugging the attached process, you can use
the `detach' command to release it from GDB control. Detaching
the process continues its execution. 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 (*note Optional
warnings and messages: Messages/Warnings.).
------------- End Included Info Nodes -------------
