This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[pushed] Remove documention of dead "target vxworks"


On 09/16/2014 01:04 PM, Joel Brobecker wrote:
>> Oh, this stuff is still documented in the manual too.
>>
>> Would you miss anything removed below?
> 
> I won't. We made a major rewrite of the documentation at the time
> when we proposed the inclusion of support for VxWorks 5.x and 6.x.
> 
> Thanks, Pedro.

Thanks Joel.  

I went ahead and pushed it in, as below, considering it an
obvious patch.

-------
>From deb8ff2b7afbdfae3c10def598977c4690f7056b Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 16 Sep 2014 16:38:12 +0100
Subject: [PATCH] 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.
---
 gdb/doc/ChangeLog   |   6 ++
 gdb/doc/gdb.texinfo | 174 ++--------------------------------------------------
 2 files changed, 10 insertions(+), 170 deletions(-)

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 98ff38b..053fd36 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
 
-- 
1.9.3



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]