Remove documention of dead "target vxworks"

"target vxworks" and friends have been removed 10 years ago already:

  commit e84ecc995d
  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.
This commit is contained in:
Pedro Alves 2014-09-16 16:38:12 +01:00
parent 0bfdf32fa1
commit deb8ff2b7a
2 changed files with 10 additions and 170 deletions

View File

@ -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.

View File

@ -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