aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc/gdbinv-s.m4
diff options
context:
space:
mode:
authorK. Richard Pixley <rich@cygnus>1992-12-08 04:59:31 +0000
committerK. Richard Pixley <rich@cygnus>1992-12-08 04:59:31 +0000
commit43bbd567f2d928b2628e508ee9c75a3920e26b4d (patch)
tree21f1ab246e1a3f963e73c3662bc1d44f591349a1 /gdb/doc/gdbinv-s.m4
parenta362ee23634a2f9ce9642eab09592e8ff6ae509b (diff)
downloadgdb-43bbd567f2d928b2628e508ee9c75a3920e26b4d.zip
gdb-43bbd567f2d928b2628e508ee9c75a3920e26b4d.tar.gz
gdb-43bbd567f2d928b2628e508ee9c75a3920e26b4d.tar.bz2
recording file death
Diffstat (limited to 'gdb/doc/gdbinv-s.m4')
-rwxr-xr-xgdb/doc/gdbinv-s.m4427
1 files changed, 0 insertions, 427 deletions
diff --git a/gdb/doc/gdbinv-s.m4 b/gdb/doc/gdbinv-s.m4
index e0814be..e69de29 100755
--- a/gdb/doc/gdbinv-s.m4
+++ b/gdb/doc/gdbinv-s.m4
@@ -1,427 +0,0 @@
-_dnl__ -*- Texinfo -*-
-_dnl__ Copyright (c) 1990 1991 Free Software Foundation, Inc.
-_dnl__ This file is part of the source for the GDB manual.
-@c M4 FRAGMENT $Id$
-@c This text diverted to "Remote Debugging" section in general case;
-@c however, if we're doing a manual specifically for one of these, it
-@c belongs up front (in "Getting In and Out" chapter).
-_if__(_I960__)
-_if__(!_GENERIC__)
-@node i960-Nindy Remote, EB29K Remote, Mode Options, Starting _GDBN__
-_fi__(!_GENERIC__)
-_if__(_GENERIC__)
-@node i960-Nindy Remote, EB29K Remote, Remote, Remote
-_fi__(_GENERIC__)
-@subsection _GDBN__ with a Remote i960 (Nindy)
-
-@cindex Nindy
-@cindex i960
-@dfn{Nindy} is a ROM Monitor program for Intel 960 target systems. When
-_GDBN__ is configured to control a remote Intel 960 using Nindy, you can
-tell _GDBN__ how to connect to the 960 in several ways:
-
-@itemize @bullet
-@item
-Through command line options specifying serial port, version of the
-Nindy protocol, and communications speed;
-
-@item
-By responding to a prompt on startup;
-
-@item
-By using the @code{target} command at any point during your _GDBN__
-session. @xref{Target Commands}.
-
-@end itemize
-
-@menu
-* Nindy Startup:: Startup with Nindy
-* Nindy Options:: Options for Nindy
-* Nindy reset:: Nindy Reset Command
-@end menu
-
-@node Nindy Startup, Nindy Options, i960-Nindy Remote, i960-Nindy Remote
-@subsubsection Startup with Nindy
-
-If you simply start @code{_GDBN__} without using any command-line
-options, you are prompted for what serial port to use, @emph{before} you
-reach the ordinary _GDBN__ prompt:
-@example
-Attach /dev/ttyNN -- specify NN, or "quit" to quit:
-@end example
-@noindent
-Respond to the prompt with whatever suffix (after @samp{/dev/tty})
-identifies the serial port you want to use. You can, if you choose,
-simply start up with no Nindy connection by responding to the prompt
-with an empty line. If you do this, and later wish to attach to Nindy,
-use @code{target} (@pxref{Target Commands}).
-
-@node Nindy Options, Nindy reset, Nindy Startup, i960-Nindy Remote
-@subsubsection Options for Nindy
-
-These are the startup options for beginning your _GDBN__ session with a
-Nindy-960 board attached:
-
-@table @code
-@item -r @var{port}
-Specify the serial port name of a serial interface to be used to connect
-to the target system. This option is only available when _GDBN__ is
-configured for the Intel 960 target architecture. You may specify
-@var{port} as any of: a full pathname (e.g. @samp{-r /dev/ttya}), a
-device name in @file{/dev} (e.g. @samp{-r ttya}), or simply the unique
-suffix for a specific @code{tty} (e.g. @samp{-r a}).
-
-@item -O
-(An uppercase letter ``O'', not a zero.) Specify that _GDBN__ should use
-the ``old'' Nindy monitor protocol to connect to the target system.
-This option is only available when _GDBN__ is configured for the Intel 960
-target architecture.
-
-@quotation
-@emph{Warning:} if you specify @samp{-O}, but are actually trying to
-connect to a target system that expects the newer protocol, the connection
-will fail, appearing to be a speed mismatch. _GDBN__ will repeatedly
-attempt to reconnect at several different line speeds. You can abort
-this process with an interrupt.
-@end quotation
-
-@item -brk
-Specify that _GDBN__ should first send a @code{BREAK} signal to the target
-system, in an attempt to reset it, before connecting to a Nindy target.
-
-@quotation
-@emph{Warning:} Many target systems do not have the hardware that this
-requires; it only works with a few boards.
-@end quotation
-
-@end table
-
-The standard @samp{-b} option controls the line speed used on the serial
-port.
-
-@node Nindy reset, , Nindy Options, i960-Nindy Remote
-@c @group
-@subsubsection Nindy Reset Command
-@table @code
-@item reset
-@kindex reset
-For a Nindy target, this command sends a ``break'' to the remote target
-system; this is only useful if the target has been equipped with a
-circuit to perform a hard reset (or some other interesting action) when
-a break is detected.
-@end table
-@c @end group
-_fi__(_I960__)
-
-_if__(_AMD29K__)
-_if__(!_GENERIC__)
-@node EB29K Remote, VxWorks Remote, i960-Nindy Remote, Starting _GDBN__
-_fi__(!_GENERIC__)
-_if__(_GENERIC__)
-@node EB29K Remote, VxWorks Remote, i960-Nindy Remote, Remote
-_fi__(_GENERIC__)
-@subsection _GDBN__ with a Remote EB29K
-
-@cindex EB29K board
-@cindex running 29K programs
-
-To use _GDBN__ from a Unix system to run programs on AMD's EB29K
-board in a PC, you must first connect a serial cable between the PC
-and a serial port on the Unix system. In the following, we assume
-you've hooked the cable between the PC's @file{COM1} port and
-@file{/dev/ttya} on the Unix system.
-
-@menu
-* Comms (EB29K):: Communications Setup
-* _GDBP__-EB29K:: EB29K cross-debugging
-* Remote Log:: Remote Log
-@end menu
-
-@node Comms (EB29K), _GDBP__-EB29K, EB29K Remote, EB29K Remote
-@subsubsection Communications Setup
-The next step is to set up the PC's port, by doing something like the
-following in DOS on the PC:
-_0__@example
-C:\> MODE com1:9600,n,8,1,none
-_1__@end example
-@noindent
-This example---run on an MS DOS 4.0 system---sets the PC port to 9600
-bps, no parity, eight data bits, one stop bit, and no ``retry'' action;
-you must match the communications parameters when establishing the Unix
-end of the connection as well.
-@c FIXME: Who knows what this "no retry action" crud from the DOS manual may
-@c mean? It's optional; leave it out? ---pesch@cygnus.com, 25feb91
-
-To give control of the PC to the Unix side of the serial line, type
-the following at the DOS console:
-_0__@example
-C:\> CTTY com1
-_1__@end example
-@noindent
-(Later, if you wish to return control to the DOS console, you can use
-the command @code{CTTY con}---but you must send it over the device that
-had control, in our example over the @file{COM1} serial line).
-
-From the Unix host, use a communications program such as @code{tip} or
-@code{cu} to communicate with the PC; for example,
-@example
-cu -s 9600 -l /dev/ttya
-@end example
-@noindent
-The @code{cu} options shown specify, respectively, the linespeed and the
-serial port to use. If you use @code{tip} instead, your command line
-may look something like the following:
-@example
-tip -9600 /dev/ttya
-@end example
-@noindent
-Your system may define a different name where our example uses
-@file{/dev/ttya} as the argument to @code{tip}. The communications
-parameters, including what port to use, are associated with the
-@code{tip} argument in the ``remote'' descriptions file---normally the
-system table @file{/etc/remote}.
-@c FIXME: What if anything needs doing to match the "n,8,1,none" part of
-@c the DOS side's comms setup? cu can support -o (odd
-@c parity), -e (even parity)---apparently no settings for no parity or
-@c for character size. Taken from stty maybe...? John points out tip
-@c can set these as internal variables, eg ~s parity=none; man stty
-@c suggests that it *might* work to stty these options with stdin or
-@c stdout redirected... ---pesch@cygnus.com, 25feb91
-
-@kindex EBMON
-Using the @code{tip} or @code{cu} connection, change the DOS working
-directory to the directory containing a copy of your 29K program, then
-start the PC program @code{EBMON} (an EB29K control program supplied
-with your board by AMD). You should see an initial display from
-@code{EBMON} similar to the one that follows, ending with the
-@code{EBMON} prompt @samp{#}---
-_0__@example
-C:\> G:
-
-G:\> CD \usr\joe\work29k
-
-G:\USR\JOE\WORK29K> EBMON
-Am29000 PC Coprocessor Board Monitor, version 3.0-18
-Copyright 1990 Advanced Micro Devices, Inc.
-Written by Gibbons and Associates, Inc.
-
-Enter '?' or 'H' for help
-
-PC Coprocessor Type = EB29K
-I/O Base = 0x208
-Memory Base = 0xd0000
-
-Data Memory Size = 2048KB
-Available I-RAM Range = 0x8000 to 0x1fffff
-Available D-RAM Range = 0x80002000 to 0x801fffff
-
-PageSize = 0x400
-Register Stack Size = 0x800
-Memory Stack Size = 0x1800
-
-CPU PRL = 0x3
-Am29027 Available = No
-Byte Write Available = Yes
-
-# ~.
-_1__@end example
-
-Then exit the @code{cu} or @code{tip} program (done in the example by
-typing @code{~.} at the @code{EBMON} prompt). @code{EBMON} will keep
-running, ready for _GDBN__ to take over.
-
-For this example, we've assumed what is probably the most convenient
-way to make sure the same 29K program is on both the PC and the Unix
-system: a PC/NFS connection that establishes ``drive @code{G:}'' on the
-PC as a file system on the Unix host. If you don't have PC/NFS or
-something similar connecting the two systems, you must arrange some
-other way---perhaps floppy-disk transfer---of getting the 29K program
-from the Unix system to the PC; _GDBN__ will @emph{not} download it over the
-serial line.
-
-@node _GDBP__-EB29K, Remote Log, Comms (EB29K), EB29K Remote
-@subsubsection EB29K cross-debugging
-Finally, @code{cd} to the directory containing an image of your 29K
-program on the Unix system, and start _GDBN__---specifying as argument the
-name of your 29K program:
-@example
-cd /usr/joe/work29k
-_GDBP__ myfoo
-@end example
-Now you can use the @code{target} command:
-@example
-target amd-eb /dev/ttya 9600 MYFOO
-@end example
-@c FIXME: test above 'target amd-eb' as spelled, with caps! caps are meant to
-@c emphasize that this is the name as seen by DOS (since I think DOS is
-@c single-minded about case of letters). ---pesch@cygnus.com, 25feb91
-
-@noindent
-In this example, we've assumed your program is in a file called
-@file{myfoo}. Note that the filename given as the last argument to
-@code{target amd-eb} should be the name of the program as it appears to DOS.
-In our example this is simply @code{MYFOO}, but in general it can include
-a DOS path, and depending on your transfer mechanism may not resemble
-the name on the Unix side.
-
-At this point, you can set any breakpoints you wish; when you're ready
-to see your program run on the 29K board, use the _GDBN__ command
-@code{run}.
-
-To stop debugging the remote program, use the _GDBN__ @code{detach}
-command.
-
-To return control of the PC to its console, use @code{tip} or @code{cu}
-once again, after your _GDBN__ session has concluded, to attach to
-@code{EBMON}. You can then type the command @code{q} to shut down
-@code{EBMON}, returning control to the DOS command-line interpreter.
-Type @code{CTTY con} to return command input to the main DOS console,
-and type @kbd{~.} to leave @code{tip} or @code{cu}.
-
-@node Remote Log, , _GDBP__-EB29K, EB29K Remote
-@subsubsection Remote Log
-@kindex eb.log
-@cindex log file for EB29K
-The @code{target amd-eb} command creates a file @file{eb.log} in the
-current working directory, to help debug problems with the connection.
-@file{eb.log} records all the output from @code{EBMON}, including echoes
-of the commands sent to it. Running @samp{tail -f} on this file in
-another window often helps to understand trouble with @code{EBMON}, or
-unexpected events on the PC side of the connection.
-_fi__(_AMD29K__)
-
-_if__(_VXWORKS__)
-_if__(!_GENERIC__)
-@node VxWorks Remote, , EB29K Remote, Starting _GDBN__
-_fi__(!_GENERIC__)
-_if__(_GENERIC__)
-@node VxWorks Remote, , EB29K Remote, Remote
-_fi__(_GENERIC__)
-@subsection _GDBN__ and VxWorks
-@cindex VxWorks
-_GDBN__ enables developers to spawn and debug tasks running on networked
-VxWorks targets from a Unix host. Already-running tasks spawned from
-the VxWorks shell can also be debugged. _GDBN__ uses code that runs on
-both the UNIX host and on the VxWorks target. The program
-@code{_GDBP__} is installed and executed on the UNIX host.
-
-The remote debugging interface (RDB) routines are installed and executed
-on the VxWorks target. These routines are included in the VxWorks library
-@file{rdb.a} and are incorporated into the system image when source-level
-debugging is enabled in the VxWorks configuration.
-
-@kindex INCLUDE_RDB
-You can define @code{INCLUDE_RDB} in the VxWorks configuration file
-@file{configAll.h} to include the RDB interface routines and spawn the
-source debugging task @code{tRdbTask} when VxWorks is booted. For more
-information on configuring and remaking VxWorks, see the @cite{VxWorks
-Programmer's Guide}.
-
-Once you have included the RDB interface in your VxWorks system image
-and set your Unix execution search path to find _GDBN__, you are ready
-to run _GDBN__. From your UNIX host, type:
-
-@smallexample
-% _GDBP__
-@end smallexample
-
-_GDBN__ will come up showing the prompt:
-
-@smallexample
-(_GDBP__)
-@end smallexample
-
-@menu
-* VxWorks connection:: Connecting to VxWorks
-* VxWorks download:: VxWorks Download
-* VxWorks attach:: Running Tasks
-@end menu
-
-@node VxWorks connection, VxWorks download, VxWorks Remote, VxWorks Remote
-@subsubsection Connecting to VxWorks
-
-The _GDBN__ command @code{target} lets you connect to a VxWorks target on the
-network. To connect to a target whose host name is ``@code{tt}'', type:
-
-@smallexample
-(_GDBP__) target vxworks tt
-@end smallexample
-
-_GDBN__ will display a message similar to the following:
-
-@smallexample
-Attaching remote machine across net... Success!
-@end smallexample
-
-_GDBN__ will then attempt to read the symbol tables of any object
-modules loaded into the VxWorks target since it was last booted.
-_GDBN__ locates these files by searching the directories listed in the
-command search path (@pxref{Environment}); if it fails to find an
-object file, it will display a message such as:
-
-@smallexample
-prog.o: No such file or directory.
-@end smallexample
-
-This will cause the @code{target} command to abort. When this happens,
-you should add the appropriate directory to the search path, with the
-_GDBN__ command @code{path}, and execute the @code{target} command
-again.
-
-@node VxWorks download, VxWorks attach, VxWorks connection, VxWorks Remote
-@subsubsection VxWorks Download
-
-@cindex download to VxWorks
-If you have connected to the VxWorks target and you want to debug an
-object that has not yet been loaded, you can use the _GDBN__ @code{load}
-command to download a file from UNIX to VxWorks incrementally. The
-object file given as an argument to the @code{load} command is actually
-opened twice: first by the VxWorks target in order to download the code,
-then by _GDBN__ in order to read the symbol table. This can lead to
-problems if the current working directories on the two systems differ.
-It is simplest to set the working directory on both systems to the
-directory in which the object file resides, and then to reference the
-file by its name, without any path. Thus, to load a program
-@file{prog.o}, residing in @file{wherever/vw/demo/rdb}, on VxWorks type:
-
-@smallexample
--> cd "wherever/vw/demo/rdb"
-@end smallexample
-
-On _GDBN__ type:
-
-@smallexample
-(_GDBP__) cd wherever/vw/demo/rdb
-(_GDBP__) load prog.o
-@end smallexample
-
-_GDBN__ will display a response similar to the following:
-
-@smallexample
-Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
-@end smallexample
-
-You can also use the @code{load} command to reload an object module
-after editing and recompiling the corresponding source file. Note that
-this will cause _GDBN__ to delete all currently-defined breakpoints,
-auto-displays, and convenience variables, and to clear the value
-history. (This is necessary in order to preserve the integrity of
-debugger data structures that reference the target system's symbol
-table.)
-
-@node VxWorks attach, , VxWorks download, VxWorks Remote
-@subsubsection Running Tasks
-
-@cindex running VxWorks tasks
-You can also attach to an existing task using the @code{attach} command as
-follows:
-
-@smallexample
-(_GDBP__) attach @var{task}
-@end smallexample
-
-where @var{task} is the VxWorks hexadecimal task ID. The task can be running
-or suspended when you attach to it. If running, it will be suspended at
-the time of attachment.
-
-_fi__(_VXWORKS__)