From patchwork Tue Sep 16 11:53:55 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 2858 Received: (qmail 31214 invoked by alias); 16 Sep 2014 11:54:04 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 31203 invoked by uid 89); 16 Sep 2014 11:54:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 16 Sep 2014 11:54:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8GBrw6N005609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 16 Sep 2014 07:53:58 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8GBrtUB025344; Tue, 16 Sep 2014 07:53:56 -0400 Message-ID: <541824D3.10708@redhat.com> Date: Tue, 16 Sep 2014 12:53:55 +0100 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Pedro Alves , Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Remove support for testing against dead "target vxworks" References: <1410561773-17974-1-git-send-email-palves@redhat.com> <20140915135901.GL4871@adacore.com> <5418218C.6030905@redhat.com> In-Reply-To: <5418218C.6030905@redhat.com> On 09/16/2014 12:39 PM, Pedro Alves wrote: > On 09/15/2014 02:59 PM, Joel Brobecker wrote: >>> Tested on x86_64 Fedora 20, native and gdbserver. >>> >>> gdb/testsuite/ >>> 2014-09-12 Pedro Alves >>> >>> * config/vx.exp, config/vxworks.exp, config/vxworks29k.exp: Delete >>> files. >>> * gdb.base/a2-run.exp: Remove all code guarded by istarget >>> "*-*-vxworks*" throughout. >>> * gdb.base/break.exp: Likewise. >>> * gdb.base/default.exp: Likewise. >>> * gdb.base/scope.exp: Likewise. >>> * gdb.base/sepdebug.exp: Likewise. >>> * gdb.base/break.c: Remove all code guarded by #ifdef vxworks >>> throughout. >>> * gdb.base/run.c: Likewise. >>> * gdb.base/sepdebug.c: Likewise. >>> * gdb.hp/gdb.aCC/run.c: Likewise. >>> * gdb.reverse/until-reverse.c: Likewise. >>> * lib/gdb.exp (gdb_compile): Remove is_vxworks branch. >> >> Thanks for doing this, Pedro. This looks good to me. Oh, this stuff is still documented in the manual too. Would you miss anything removed below? gdb/doc/gdb.texinfo | 174 ++-------------------------------------------------- 1 file changed, 4 insertions(+), 170 deletions(-) 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