aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-09-16 16:38:12 +0100
committerPedro Alves <palves@redhat.com>2014-09-16 16:38:12 +0100
commitdeb8ff2b7afbdfae3c10def598977c4690f7056b (patch)
treeb522d80a4d6a3d7c7dac88639842f1b65301935a /gdb
parent0bfdf32fa101021ad0d11dd3ae945c823f4b07ac (diff)
downloadgdb-deb8ff2b7afbdfae3c10def598977c4690f7056b.zip
gdb-deb8ff2b7afbdfae3c10def598977c4690f7056b.tar.gz
gdb-deb8ff2b7afbdfae3c10def598977c4690f7056b.tar.bz2
Remove documention of dead "target vxworks"
"target vxworks" and friends have been removed 10 years ago already: commit e84ecc995d6a5e4e9114d3cea61717b8a573afb6 Author: Andrew Cagney <cagney@redhat.com> AuthorDate: Sat Nov 13 23:10:02 2004 +0000 2004-11-13 Andrew Cagney <cagney@gnu.org> * configure.tgt: Delete i[34567]86-*-vxworks*, m68*-netx-*, m68*-*-vxworks*, mips*-*-vxworks*, powerpc-*-vxworks*, and sparc-*-vxworks*. * NEWS: Mention that vxworks was deleted. (...) * remote-vxmips.c, remote-vx.c: Delete. * remote-vx68.c: Delete. (...) This removes related leftover cruft from the manual. gdb/doc/ 2014-09-16 Pedro Alves <palves@redhat.com> * gdb.texinfo (Starting) <run command>: Don't mention VxWorks. (Embedded OS): Remove VxWorks menu entry. (VxWorks): Remove node.
Diffstat (limited to 'gdb')
-rw-r--r--gdb/doc/ChangeLog6
-rw-r--r--gdb/doc/gdb.texinfo174
2 files changed, 10 insertions, 170 deletions
diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 98ff38b..053fd36d 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,9 @@
+2014-09-16 Pedro Alves <palves@redhat.com>
+
+ * gdb.texinfo (Starting) <run command>: Don't mention VxWorks.
+ (Embedded OS): Remove VxWorks menu entry.
+ (VxWorks): Remove node.
+
2014-09-13 Doug Evans <xdje42@gmail.com>
* gdb.texinfo (Signaling): Document new queue-signal command.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 037806f..1bb1c0c 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -1977,10 +1977,10 @@ format in @value{GDBN}.
@item run
@itemx r
Use the @code{run} command to start your program under @value{GDBN}.
-You must first specify the program name (except on VxWorks) with an
-argument to @value{GDBN} (@pxref{Invocation, ,Getting In and Out of
-@value{GDBN}}), or by using the @code{file} or @code{exec-file} command
-(@pxref{Files, ,Commands to Specify Files}).
+You must first specify the program name with an argument to
+@value{GDBN} (@pxref{Invocation, ,Getting In and Out of
+@value{GDBN}}), or by using the @code{file} or @code{exec-file}
+command (@pxref{Files, ,Commands to Specify Files}).
@end table
@@ -20513,175 +20513,9 @@ This section describes configurations involving the debugging of
embedded operating systems that are available for several different
architectures.
-@menu
-* VxWorks:: Using @value{GDBN} with VxWorks
-@end menu
-
@value{GDBN} includes the ability to debug programs running on
various real-time operating systems.
-@node VxWorks
-@subsection Using @value{GDBN} with VxWorks
-
-@cindex VxWorks
-
-@table @code
-
-@kindex target vxworks
-@item target vxworks @var{machinename}
-A VxWorks system, attached via TCP/IP. The argument @var{machinename}
-is the target system's machine name or IP address.
-
-@end table
-
-On VxWorks, @code{load} links @var{filename} dynamically on the
-current target system as well as adding its symbols in @value{GDBN}.
-
-@value{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. @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. (It may be
-installed with the name @code{vxgdb}, to distinguish it from a
-@value{GDBN} for debugging programs on the host itself.)
-
-@table @code
-@item VxWorks-timeout @var{args}
-@kindex vxworks-timeout
-All VxWorks-based targets now support the option @code{vxworks-timeout}.
-This option is set by the user, and @var{args} represents the number of
-seconds @value{GDBN} waits for responses to rpc's. You might use this if
-your VxWorks target is a slow software simulator or is on the far side
-of a thin network line.
-@end table
-
-The following information on connecting to VxWorks was current when
-this manual was produced; newer releases of VxWorks may use revised
-procedures.
-
-@findex INCLUDE_RDB
-To use @value{GDBN} with VxWorks, you must rebuild your VxWorks kernel
-to include the remote debugging interface routines in the VxWorks
-library @file{rdb.a}. To do this, define @code{INCLUDE_RDB} in the
-VxWorks configuration file @file{configAll.h} and rebuild your VxWorks
-kernel. The resulting kernel contains @file{rdb.a}, and spawns the
-source debugging task @code{tRdbTask} when VxWorks is booted. For more
-information on configuring and remaking VxWorks, see the manufacturer's
-manual.
-@c VxWorks, see the @cite{VxWorks Programmer's Guide}.
-
-Once you have included @file{rdb.a} 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, run @code{@value{GDBP}} (or
-@code{vxgdb}, depending on your installation).
-
-@value{GDBN} comes up showing the prompt:
-
-@smallexample
-(vxgdb)
-@end smallexample
-
-@menu
-* VxWorks Connection:: Connecting to VxWorks
-* VxWorks Download:: VxWorks download
-* VxWorks Attach:: Running tasks
-@end menu
-
-@node VxWorks Connection
-@subsubsection Connecting to VxWorks
-
-The @value{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
-(vxgdb) target vxworks tt
-@end smallexample
-
-@need 750
-@value{GDBN} displays messages like these:
-
-@smallexample
-Attaching remote machine across net...
-Connected to tt.
-@end smallexample
-
-@need 1000
-@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 displays a message such as:
-
-@smallexample
-prog.o: No such file or directory.
-@end smallexample
-
-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. 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:
-
-@smallexample
--> cd "@var{vxpath}/vw/demo/rdb"
-@end smallexample
-
-@noindent
-Then, in @value{GDBN}, type:
-
-@smallexample
-(vxgdb) cd @var{hostpath}/vw/demo/rdb
-(vxgdb) load prog.o
-@end smallexample
-
-@value{GDBN} displays a response similar to this:
-
-@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 makes @value{GDBN} 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's data structures that reference the target system's symbol
-table.)
-
-@node VxWorks Attach
-@subsubsection Running Tasks
-
-@cindex running VxWorks tasks
-You can also attach to an existing task using the @code{attach} command as
-follows:
-
-@smallexample
-(vxgdb) attach @var{task}
-@end smallexample
-
-@noindent
-where @var{task} is the VxWorks hexadecimal task ID. The task can be running
-or suspended when you attach to it. Running tasks are suspended at
-the time of attachment.
-
@node Embedded Processors
@section Embedded Processors