aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc/gdbinv-s.texi
diff options
context:
space:
mode:
authorRoland Pesch <pesch@cygnus>1993-06-16 19:03:53 +0000
committerRoland Pesch <pesch@cygnus>1993-06-16 19:03:53 +0000
commitd55320a07b71fcf757f174f3fc2cf2ca10b4e611 (patch)
tree734cbee9f8116cdeed2378020a640d4a4afaf17b /gdb/doc/gdbinv-s.texi
parent6cbc2dbafd4d02553ad6d195ddf71af50e84522f (diff)
downloadgdb-d55320a07b71fcf757f174f3fc2cf2ca10b4e611.zip
gdb-d55320a07b71fcf757f174f3fc2cf2ca10b4e611.tar.gz
gdb-d55320a07b71fcf757f174f3fc2cf2ca10b4e611.tar.bz2
* gdb.texinfo (Copying): delete this node and references to it;
RMS says this manual need not carry GPL. (passim): Improvements from last round at FSF, largely due to Ian Taylor review, and minor formatting improvements. * gdbinv-s.texi (passim): Improvements from last round at FSF, largely due to Ian Taylor review. (Debug Session): minor edits to new text.
Diffstat (limited to 'gdb/doc/gdbinv-s.texi')
-rw-r--r--gdb/doc/gdbinv-s.texi96
1 files changed, 51 insertions, 45 deletions
diff --git a/gdb/doc/gdbinv-s.texi b/gdb/doc/gdbinv-s.texi
index 9145d94..33bf095 100644
--- a/gdb/doc/gdbinv-s.texi
+++ b/gdb/doc/gdbinv-s.texi
@@ -123,7 +123,7 @@ breakpoint. Depending on the particular situation, this may be the only
way for @value{GDBN} to get control. For instance, if your target
machine has some sort of interrupt button, you won't need to call this;
pressing the interrupt button will transfer control to
-@code{handle_exception}---in efect, to @value{GDBN}. On some machines,
+@code{handle_exception}---in effect, to @value{GDBN}. On some machines,
simply receiving characters on the serial port may also trigger a trap;
again, in that situation, you don't need to call @code{breakpoint} from
your own program---simply running @samp{target remote} from the host
@@ -209,17 +209,17 @@ breakpoint();
@item
For the 680x0 stub only, you need to provide a variable called
-exceptionHook. Normally you just use
+@code{exceptionHook}. Normally you just use
@example
void (*exceptionHook)() = 0;
@end example
-but if you, before calling @code{set_debug_traps}, set it to point to
-a function, that function will be called when the debugger continues
-from a trap (for example, bus error) which causes the debugger to be
-entered. It is passed one parameter---an @code{int} which is the
-exception number.
+but if before calling @code{set_debug_traps}, you set it to point to a
+function in your program, that function is called when
+@code{@value{GDBN}} continues after stopping on a trap (for example, bus
+error). The function indicated by @code{exceptionHook} is called with
+one parameter: an @code{int} which is the exception number.
@item
Compile and link together: your program, the @value{GDBN} debugging stub for
@@ -503,15 +503,18 @@ to its pathname.
@end table
@node EB29K Remote
-@subsection @value{GDBN} with a remote EB29K
+@subsection @value{GDBN} and the EBMON protocol for AMD29K
@cindex EB29K board
@cindex running 29K programs
-To use @value{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
+AMD distributes a 29K development board meant to fit in a PC, together
+with a DOS-hosted monitor program called @code{EBMON}. As a shorthand
+term, this development system is called the ``EB29K''. To use
+@value{GDBN} from a Unix system to run programs on the EB29K board, you
+must first connect a serial cable between the PC (which hosts the EB29K
+board) 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
@@ -742,7 +745,9 @@ sequences will get you back to the @value{GDBN} command prompt:
VxWorks targets from a Unix host. Already-running tasks spawned from
the VxWorks shell can also be debugged. @value{GDBN} uses code that runs on
both the UNIX host and on the VxWorks target. The program
-@code{@value{GDBP}} is installed and executed on the UNIX host.
+@code{gdb} is installed and executed on the UNIX host. (It may be
+installed with the name @code{vxgdb}, to distinguish it from a
+@value{GDBN} for debugging programs on the host itself.)
The following information on connecting to VxWorks was current when
this manual was produced; newer releases of VxWorks may use revised
@@ -763,16 +768,13 @@ VxWorks, see the manufacturer's manual.
Once you have included the RDB interface in your VxWorks system image
and set your Unix execution search path to find @value{GDBN}, you are ready
-to run @value{GDBN}. From your UNIX host, type:
+to run @value{GDBN}. From your UNIX host, run @code{gdb} (or
+@code{vxgdb}, depending on your installation).
-@example
-% @value{GDBP}
-@end example
-
-@value{GDBN} will come up showing the prompt:
+@value{GDBN} comes up showing the prompt:
@example
-(@value{GDBP})
+(vxgdb)
@end example
@menu
@@ -788,58 +790,62 @@ The @value{GDBN} command @code{target} lets you connect to a VxWorks target on t
network. To connect to a target whose host name is ``@code{tt}'', type:
@example
-(@value{GDBP}) target vxworks tt
+(vxgdb) target vxworks tt
@end example
-@value{GDBN} will display a message similar to the following:
+@value{GDBN} displays messages like these:
@smallexample
-Attaching remote machine across net... Success!
+Attaching remote machine across net...
+Connected to tt.
@end smallexample
-@value{GDBN} will then attempt to read the symbol tables of any object modules
+@value{GDBN} then attempts to read the symbol tables of any object modules
loaded into the VxWorks target since it was last booted. @value{GDBN} locates
these files by searching the directories listed in the command search
path (@pxref{Environment, ,Your program's environment}); if it fails
-to find an object file, it will display a message such as:
+to find an object file, it displays a message such as:
@example
prog.o: No such file or directory.
@end example
-This will cause the @code{target} command to abort. When this happens,
-you should add the appropriate directory to the search path, with the
-@value{GDBN} command @code{path}, and execute the @code{target} command
-again.
+When this happens, add the appropriate directory to the search path with
+the @value{GDBN} command @code{path}, and execute the @code{target}
+command again.
@node VxWorks Download
@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 @value{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 @value{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:
+object that has not yet been loaded, you can use the @value{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 @value{GDBN} in order to read the symbol
+table. This can lead to problems if the current working directories on
+the two systems differ. If both systems have NFS mounted the same
+filesystems, you can avoid these problems by using absolute paths.
+Otherwise, 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. For instance, a program
+@file{prog.o} may reside in @file{@var{vxpath}/vw/demo/rdb} in VxWorks
+and in @file{@var{hostpath}/vw/demo/rdb} on the host. To load this
+program, type this on VxWorks:
@example
--> cd "wherever/vw/demo/rdb"
+-> cd "@var{vxpath}/vw/demo/rdb"
@end example
-On @value{GDBN} type:
+Then, in @value{GDBN}, type:
@example
-(@value{GDBP}) cd wherever/vw/demo/rdb
-(@value{GDBP}) load prog.o
+(vxgdb) cd @var{hostpath}/vw/demo/rdb
+(vxgdb) load prog.o
@end example
-@value{GDBN} will display a response similar to the following:
+@value{GDBN} displays a response similar to this:
@smallexample
Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
@@ -861,7 +867,7 @@ You can also attach to an existing task using the @code{attach} command as
follows:
@example
-(@value{GDBP}) attach @var{task}
+(vxgdb) attach @var{task}
@end example
@noindent