espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-22 02:50:08 +08:00
Code Issues Packages Projects Releases Wiki Activity

* gdb.texinfo (Processes): New node.

Browse Source
This commit is contained in:
Jim Kingdon
1995-01-23 22:27:49 +00:00
parent 7343338436
commit 1b0c5a4fbb
2 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
gdb/doc/ChangeLog
View File

@ -1,3 +1,7 @@
Mon Jan 23 14:23:37 1995 Jim Kingdon (kingdon@lioth.cygnus.com)
* gdb.texinfo (Processes): New node.
Tue Jan 17 14:09:03 1995 Ian Lance Taylor <ian@sanguine.cygnus.com> Tue Jan 17 14:09:03 1995 Ian Lance Taylor <ian@sanguine.cygnus.com>
* remote.texi: Update documentation of set/show mipsfpu. * remote.texi: Update documentation of set/show mipsfpu.

25
gdb/doc/gdb.texinfo
View File

@ -1400,6 +1400,7 @@ already running process, or kill a child process.
* Kill Process:: Killing the child process * Kill Process:: Killing the child process
* Process Information:: Additional process information * Process Information:: Additional process information
* Threads:: Debugging programs with multiple threads * Threads:: Debugging programs with multiple threads
* Processes:: Debugging programs with multiple processes
@end ifclear @end ifclear
@end menu @end menu
@ -1985,6 +1986,30 @@ programs with multiple threads.
watchpoints in programs with multiple threads. watchpoints in programs with multiple threads.
@end ifclear @end ifclear
@node Processes
@section Debugging programs with multiple processes
@cindex fork, debugging programs which call
@cindex multiple processes
@cindex processes, multiple
@value{GDBN} has no special support for debugging programs which create
additional processes using the @code{fork} function. When a program
forks, @value{GDBN} 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 @code{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 @code{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 not occur when you don't want to run @value{GDBN}
on the child. While the child is sleeping, use the @code{ps} program to
get its process ID. Then tell @value{GDBN} (a new invocation of
@value{GDBN} if you are also debugging the parent process) to attach to
the child process (see @ref{Attach}). From that point on you can debug
the child process just like any other process which you attached to.
@node Stopping @node Stopping
@chapter Stopping and Continuing @chapter Stopping and Continuing