mirror of
https://github.com/darlinghq/darling-gdb.git
synced 2025-02-21 10:02:26 +00:00
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.
This commit is contained in:
parent
0bfdf32fa1
commit
deb8ff2b7a
@ -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.
|
||||
|
@ -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
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user