[PATCH] dejagnu framework for testing gdbserver

[PATCH] dejagnu framework for testing gdbserver

[Michael Snyder]

The old gdb/testsuite/config/gdbserver.exp had not been
used or updated since 1995, so I've rewritten it from
scratch.  My new version has been tested on linux x86
(with the same machine for host and target).  Extensions
and enhancements welcome.  

Since it's essentially a new file, I'll just include it
here instead of a context diff.

2000-10-19  Michael Snyder  <msnyder@cleaver.cygnus.com>

        * config/gdbserver.exp:  Rewritten from the ground up, to make
it
        compatible with the current dejagnu tree, and to make it work
with
        the new "gdbserver" in libremote.
From jtc@redback.com Thu Oct 19 16:14:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "Josef Ezra" <jezra@emc.com>
Cc: "Michael Snyder" <msnyder@redhat.com>, <gdb-patches@sources.redhat.com>, "ezra, josef" <ezra_josef@emc.com>, <shagam@emc.com>, <sgordon@emc.com>
Subject: Re: tracepoints implementation: bug in byte code generating.
Date: Thu, 19 Oct 2000 16:14:00 -0000
Message-id: <5mvguo5spm.fsf@jtc.redback.com>
References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> <004e01c039d8$774c1d50$6c219fa8@lss.emc.com> <39EF3020.3F6A@redhat.com> <005b01c039f6$f46b1390$6c219fa8@lss.emc.com> <39EF381C.7EE6@redhat.com> <006101c039f9$df09df60$6c219fa8@lss.emc.com>
X-SW-Source: 2000-10/msg00126.html
Content-length: 1731

>>>>> "Josef" == Josef Ezra <jezra@emc.com> writes:
>> Any changes to the remote protocol can be discussed
>> on this mailing list.

Josef> Actually I had in mind a 'show protocol version' command (for
Josef> backward compatibility) and a special read memory command (like
Josef> "mxxxx,lll") which can be used at target side for special reads
Josef> (in my case, it will show values in different memory scope).

For better or for worse, the remote protocol is been designed such
that support for individual features can be probed for at run time
instead of having protocol versions.

While I believe that this has allowed new command packets to be added
to the protocol expediently, I also believe that a more formal design
and review may have produced a better overall result.  Even so, if at
all possible, I think your new command should be probed at run time.

Can you offer more details about your command packet?  Is it a varient
of the 'm' command, or a new command?  What exactly do you mean by
different memory scope?  Is there a cooresponding 'M' command to write
memory?

Josef> If it will turn out to be very useful, I will suggest it in
Josef> this forum.

In my remote II protocol spec (which regulars on the list know that
I've been working on-and-off for about a year, but has never been
ready enough to publish :-( ), the read and write memory commands
take a memory space argument.  I was thinking about it being used
(on a target specific basis) for things like the x86 i/o ports or
PCI config space, etc.  I haven't thought about how such things 
would get through GDB to the CLI, but I thought it was important 
enough that the protocol support such things.  

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Oct 19 16:32:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Till Straumann <strauman@SLAC.Stanford.EDU>
Cc: gdb-patches@sources.redhat.com
Subject: Re: gdb and the vxworks target
Date: Thu, 19 Oct 2000 16:32:00 -0000
Message-id: <5mog0g5rva.fsf@jtc.redback.com>
References: <39EF530C.8EC0F049@slac.stanford.edu>
X-SW-Source: 2000-10/msg00127.html
Content-length: 2651

>>>>> "Till" == Till Straumann <strauman@SLAC.Stanford.EDU> writes:
Till> As of Version 5.4, WindRiver has more or less silently removed
Till> support for the RDB protocol. This means that the gdb target
Till> `vxworks' no longer works with VxWorks versions later than 5.3

Till> However, there is another server on the vxWorks target talking a
Till> different protocol, WDB, which at least is quite well documented.

It's OK, but at least in the copy of the WDB spec I have there are
some holes, such as in what set and at what offset each register is
located for the get/fetch register commands.  I wasn't able to find
the WTX or WDB specs in the Tornado II documentation --- I got the
impression that they (WRS) wants to hide such details under their
proprietary libraries.  That makes it a bit difficult for third party,
open source, multi-platform tools like GDB.

We're using a WDB back end I hacked from Wind River's vxgdb sources
remote-wtx.c module.  I've been meaning to re-write those bits so I
could contribute it for the last year or so.  Unfortunately, it's a
fairly low on my priority list.

If your code isn't similarly encumbered, and you're able to contribute
it, it's probably a faster route to supplying WDB support to GDB users.

Till> I added support for WDB to `remote-vx.c' which means that gdb
Till> can again talk to vxworks :-) The CPU dependent parts (a very
Till> tiny piece of code) are currently only implemented for the
Till> powerpc (I could easily add m68k, if there's any need).

Did you maintain support for RDB in the process?  While WRS has
dropped support for RDB, there may be vxworks users in the field that
still use it.  We should continue to support it if at all possible.

If you kept RDB support, how much code for RDB and WDB are shared in
remote-vx.c?  In our sources, remote-wdb is completely separate.

Till> Because WDB lacks some functionality that RDB had provided (on
Till> the other hand, WDB adds new features), I also wrote a small
Till> server which can be started on the target. This server
Till> implements a subset of the RDB protocol, essentially the parts
Till> which are necessary to remotely load files and lookup modules.

When you talk about a "small server that can be started on the target",
you're talking about something that runs on the vxWorks system, right?
Another engineer here hacked code into my remote-wdb.c to support 
remotely loading files, but it works entirely with WDB.  Can you
please explain more?

We also have a WDB multiplexor so that multiple GDBs, each connected
to a single vxWorks task, can debug a system.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From kevinb@cygnus.com Thu Oct 19 17:45:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Protoize solib.c
Date: Thu, 19 Oct 2000 17:45:00 -0000
Message-id: <1001020004548.ZM4367@ocotillo.lan>
References: <1001018035727.ZM23476@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-10/msg00128.html
Content-length: 217

On Oct 17,  8:57pm, Kevin Buettner wrote:

> 	* solib.c (LM_ADDR, LM_NEXT, LM_NAME, IGNORE_FIRST_LINK_MAP_ENTRY,
> 	open_symbol_file_object): Protoize.

Committed.

Thanks to Michael Chastain for reviewing the patch.
From kevinb@cygnus.com Thu Oct 19 18:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFC] Protoize sparc-nat.c, sparcl-tdep.c
Date: Thu, 19 Oct 2000 18:00:00 -0000
Message-id: <1001020005952.ZM4471@ocotillo.lan>
X-SW-Source: 2000-10/msg00129.html
Content-length: 2066

More protoization...

	* sparc-nat.c (fetch_core_registers): Protoize.
	* sparcl-tdep.c (download): Protoize.

Index: sparc-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-nat.c,v
retrieving revision 1.3
diff -u -r1.3 sparc-nat.c
--- sparc-nat.c	2000/07/30 01:48:27	1.3
+++ sparc-nat.c	2000/10/20 00:52:24
@@ -248,13 +248,21 @@
     }
 }
 
+/* Provide registers to GDB from a core file.
 
+   CORE_REG_SECT points to an array of bytes, which are the contents
+   of a `note' from a core file which BFD thinks might contain
+   register contents.  CORE_REG_SIZE is its size.
+
+   WHICH says which register set corelow suspects this is:
+     0 --- the general-purpose register set
+     2 --- the floating-point register set
+
+   IGNORE is unused.  */
+
 static void
-fetch_core_registers (core_reg_sect, core_reg_size, which, ignore)
-     char *core_reg_sect;
-     unsigned core_reg_size;
-     int which;
-     CORE_ADDR ignore;		/* reg addr, unused in this version */
+fetch_core_registers (char *core_reg_sect, unsigned core_reg_size,
+		      int which, CORE_ADDR ignore)
 {
 
   if (which == 0)
Index: sparcl-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparcl-tdep.c,v
retrieving revision 1.6
diff -u -r1.6 sparcl-tdep.c
--- sparcl-tdep.c	2000/07/30 01:48:27	1.6
+++ sparcl-tdep.c	2000/10/20 00:52:25
@@ -527,13 +527,10 @@
 #define LOAD_ADDRESS 0x40000000
 
 static void
-download (target_name, args, from_tty, write_routine, start_routine)
-     char *target_name;
-     char *args;
-     int from_tty;
-     void (*write_routine) (bfd * from_bfd, asection * from_sec,
-			    file_ptr from_addr, bfd_vma to_addr, int len);
-     void (*start_routine) (bfd_vma entry);
+download (char *target_name, char *args, int from_tty,
+	  void (*write_routine) (bfd *from_bfd, asection *from_sec,
+				 file_ptr from_addr, bfd_vma to_addr, int len),
+	  void (*start_routine) (bfd_vma entry))
 {
   struct cleanup *old_chain;
   asection *section;

Re: [PATCH] dejagnu framework for testing gdbserver

[Michael Snyder]

Fernando Nasser wrote:
> 
> Nice.  Can it run with the old gdbserver as well?

Yes, if gdb and gdbserver are on the same host.
I'm about to try it with them being on different hosts.
See dejagnu/baseboards/linux-gdbserver.exp and
dejagnu/baseboards/linux-libremote.exp

> 
> Thanks.
> 
> Fernando
> 
> Michael Snyder wrote:
> >
> > The old gdb/testsuite/config/gdbserver.exp had not been
> > used or updated since 1995, so I've rewritten it from
> > scratch.  My new version has been tested on linux x86
> > (with the same machine for host and target).  Extensions
> > and enhancements welcome.
> >
> > Since it's essentially a new file, I'll just include it
> > here instead of a context diff.
> >
> > 2000-10-19  Michael Snyder  <msnyder@cleaver.cygnus.com>
> >
> >         * config/gdbserver.exp:  Rewritten from the ground up, to make
> > it
> >         compatible with the current dejagnu tree, and to make it work
> > with
> >         the new "gdbserver" in libremote.
> >
> >   ----------------------------------------------------------------------------------------------------
> > # Test framework for GDB (remote protocol) using a "gdbserver",
> > # ie. a debug agent running as a native process on the same or
> > # a different host.
> >
> > #   Copyright (C) 2000, Free Software Foundation, Inc.
> >
> > # This program is free software; you can redistribute it and/or modify
> > # it under the terms of the GNU General Public License as published by
> > # the Free Software Foundation; either version 2 of the License, or
> > # (at your option) any later version.
> > #
> > # This program is distributed in the hope that it will be useful,
> > # but WITHOUT ANY WARRANTY; without even the implied warranty of
> > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > # GNU General Public License for more details.
> > #
> > # You should have received a copy of the GNU General Public License
> > # along with this program; if not, write to the Free Software
> > # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> >
> > # Please email any bugs, comments, and/or additions to this file to:
> > # bug-gdb@prep.ai.mit.edu
> >
> > # This file was written by Michael Snyder. (msnyder@redhat.com)
> >
> > #
> > # This module to be used for testing gdb with a "gdbserver"
> > # built either from libremote or from gdb/gdbserver.
> > #
> >
> > # Load the basic testing library, and the remote stuff.
> > load_lib ../config/monitor.exp
> >
> > #
> > # To be addressed or set in your baseboard config file:
> > #
> > #   set_board_info gdb_protocol "remote"
> > #       Unles you have a gdbserver that uses a different protocol...
> > #
> > #   set_board_info use_gdb_stub 1
> > #       This tells the rest of the test suite not to do things
> > #       like "run" which don't work well on remote targets.
> > #
> > #   set_board_info gdb,do_reload_on_run 1
> > #       Unles you have a gdbserver that can handle multiple sessions.
> > #
> > #   set_board_info noargs 1
> > #       At present there is no provision in the remote protocol
> > #       for passing arguments.  This test framework does not
> > #       address the issue, so it's best to set this variable
> > #       in your baseboard configuration file.
> > #       FIXME: there's no reason why the test harness couldn't
> > #       pass commandline args when it spawns gdbserver.
> > #
> > #   set_board_info gdb,noinferiorio 1
> > #       Neither the traditional gdbserver nor the one in libremote
> > #       can presently capture stdout and relay it to GDB via the
> > #       'O' packet.  This means that tests involving printf will
> > #       fail unles you set this varibale in your baseboard
> > #       configuration file.
> > #
> > #   set_board_info gdb,no_hardware_watchpoints 1
> > #       Unles you have a gdbserver that supports hardware watchpoints.
> > #       FIXME: gdb should detect if the target doesn't support them,
> > #       and fall back to using software watchpoints.
> > #
> > #   set_board_info gdb_server_prog
> > #       This will be the path to the gdbserver program you want to test.
> > #       Defaults to "gdbserver".
> > #
> > #   set_board_info sockethost
> > #       The name of the host computer whose socket is being used.
> > #       Defaults to "localhost".  Note: old gdbserver requires
> > #       that you define this, but libremote/gdbserver does not.
> > #
> > #   set_board_info socketport
> > #       Port id to use for socket connection.  If not set explicitly,
> > #       it will start at "2345" and increment for each use.
> > #
> >
> > #
> > # gdb_load -- load a file into the debugger.
> > #             return a -1 if anything goes wrong.
> > #
> >
> > global server_exec;
> > global portnum;
> > set portnum "2345";
> >
> > proc gdb_load { args } {
> >     global server_exec;
> >     global portnum;
> >
> >     # Port id -- either specified in baseboard file, or managed here.
> >     if [target_info exists gdb,socketport] {
> >         set portnum [target_info gdb,socketport];
> >     } else {
> >         # Bump the port number to avoid conflicts with hung ports.
> >         incr portnum;
> >     }
> >
> >     # Extract the local and remote host ids from the target board struct.
> >
> >     if [target_info exists sockethost] {
> >         set debughost  [target_info sockethost];
> >     } else {
> >         set debughost "localhost:";
> >     }
> >     # Extract the protocol
> >     if [target_info exists gdb_protocol] {
> >         set protocol [target_info gdb_protocol];
> >     } else {
> >         set protocol "remote";
> >     }
> >
> >     # Extract the name of the gdbserver, if known (default 'gdbserver').
> >     if [target_info exists gdb_server_prog] {
> >         set gdbserver [target_info gdb_server_prog];
> >     } else {
> >         set gdbserver "gdbserver";
> >     }
> >     # Extract the socket hostname
> >     if [target_info exists sockethost] {
> >         set sockethost [target_info sockethost];
> >     } else {
> >         set sockethost ""
> >     }
> >
> >     # Export the host:port pair.
> >     set gdbport $debughost$portnum;
> >
> >     if { $args == "" || $args == "{}" } {
> >         if [info exists server_exec] {
> >             set args $server_exec;
> >         } else {
> >             send_gdb "info files\n";
> >             gdb_expect 30 {
> >                 -re "Symbols from \"(\[^\"\]+)\"" {
> >                     set args $expect_out(1,string);
> >                     exp_continue;
> >                 }
> >                 -re "Local exec file:\[\r\n\]+\[ \t\]*`(\[^'\]+)'," {
> >                     set args $expect_out(1,string);
> >                     exp_continue;
> >                 }
> >                 -re "$gdb_prompt $" { }
> >             }
> >         }
> >     }
> >
> >     # remember new exec file
> >     set server_exec $args;
> >
> >     # Fire off the debug agent
> >     remote_spawn host \
> >             "$gdbserver $sockethost$portnum $args >& /dev/null < /dev/null &" \
> >             writeonly
> >
> >     # Give it a little time to establish
> >     sleep 2
> >
> >     # tell gdb what file we are debugging
> >     if [gdb_file_cmd $args] {
> >         return -1;
> >     }
> >
> >     # attach to the "serial port"
> >     gdb_target_cmd $protocol $gdbport;
> >
> >     return 0;
> > }
> 
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
From msnyder@redhat.com Fri Oct 20 11:37:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Josef Ezra <jezra@emc.com>
Cc: jtc@redback.com, gdb-patches@sources.redhat.com, "ezra, josef" <ezra_josef@emc.com>, shagam@emc.com, sgordon@emc.com
Subject: Re: tracepoints implementation: bug in byte code generating.
Date: Fri, 20 Oct 2000 11:37:00 -0000
Message-id: <39F090F3.2DDC@redhat.com>
References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> <004e01c039d8$774c1d50$6c219fa8@lss.emc.com> <39EF3020.3F6A@redhat.com> <005b01c039f6$f46b1390$6c219fa8@lss.emc.com> <39EF381C.7EE6@redhat.com> <006101c039f9$df09df60$6c219fa8@lss.emc.com> <5mvguo5spm.fsf@jtc.redback.com> <008501c03aad$46c9d700$6c219fa8@lss.emc.com>
X-SW-Source: 2000-10/msg00136.html
Content-length: 3845

Josef Ezra wrote:
> 
> ----- Original Message -----
> From: "J.T. Conklin" <jtc@redback.com>
> To: "Josef Ezra" <jezra@emc.com>
> Cc: "Michael Snyder" <msnyder@redhat.com>; <gdb-patches@sources.redhat.com>;
> "ezra, josef" <ezra_josef@emc.com>; <shagam@emc.com>; <sgordon@emc.com>
> Sent: Thursday, October 19, 2000 7:14 PM
> Subject: Re: tracepoints implementation: bug in byte code generating.
> 
> > >>>>> "Josef" == Josef Ezra <jezra@emc.com> writes:
> > >> Any changes to the remote protocol can be discussed
> > >> on this mailing list.
> >
> > Josef> Actually I had in mind a 'show protocol version' command (for
> > Josef> backward compatibility) and a special read memory command (like
> > Josef> "mxxxx,lll") which can be used at target side for special reads
> > Josef> (in my case, it will show values in different memory scope).
> >
> > For better or for worse, the remote protocol is been designed such
> > that support for individual features can be probed for at run time
> > instead of having protocol versions.
> >
> > While I believe that this has allowed new command packets to be added
> > to the protocol expediently, I also believe that a more formal design
> > and review may have produced a better overall result.  Even so, if at
> > all possible, I think your new command should be probed at run time.
> >
> > Can you offer more details about your command packet?  Is it a varient
> > of the 'm' command, or a new command?  What exactly do you mean by
> > different memory scope?  Is there a cooresponding 'M' command to write
> > memory?
> >
> > Josef> If it will turn out to be very useful, I will suggest it in
> > Josef> this forum.
> >
> > In my remote II protocol spec (which regulars on the list know that
> > I've been working on-and-off for about a year, but has never been
> > ready enough to publish :-( ), the read and write memory commands
> > take a memory space argument.  I was thinking about it being used
> > (on a target specific basis) for things like the x86 i/o ports or
> > PCI config space, etc.  I haven't thought about how such things
> > would get through GDB to the CLI, but I thought it was important
> > enough that the protocol support such things.
> >
> >         --jtc
> >
> > --
> > J.T. Conklin
> > RedBack Networks
> >
> 
> Hi
> 
> I thought about 'nAAAA,LLLL' and 'NAAAA,LLLL:XXXX' commands as an
> alternative for 'm' and 'M' commands. In my case (EMC SYMMETRIX) it could be
> useful for indicating the target to get those addresses from a different
> memory space. Your idea of having a memory space argument is more general
> and flexible; I will be very happy to use it.

May I ask what your separate memory spaces are?

> (May I have a copy of your remote II protocol spec? Even half-baked, it
> would be of great help.)
> 
> About the "qver" (show-version) command, I need it for the
> set-tracepoint-with-a-byte-code command. I am adding some byte-code-items
> (like trace/ref-from-other-memory-space and stop-tracing-if) to my target
> and I want gdb to determine the target abilities before it creates this
> code.

Are you aware that EMC is not the only user of tracepoints?
I am the maintainer, and I will be far more likely to accept
your changes if you consult with me on the design BEFORE 
you implement.  In particular, I am not impressed with this
idea of querying the target for a version.  This idea has been
proposed and sunk many times over the years.  I don't think
we need it.  The traditional approach is to send a command
to the stub and see if it replies.  All stubs have to be
able to "handle" commands that they don't understand (by 
sending back an empty reply).  Is there anything about
your new feature that would preclude this?  Is there anything
about your new feature that OTHER tracepoint clients might
not be interested in incorporating?

Michael
From strauman@SLAC.Stanford.EDU Fri Oct 20 11:42:00 2000
From: Till Straumann <strauman@SLAC.Stanford.EDU>
To: jtc@redback.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: gdb and the vxworks target
Date: Fri, 20 Oct 2000 11:42:00 -0000
Message-id: <39F09229.9464FC88@slac.stanford.edu>
References: <39EF530C.8EC0F049@slac.stanford.edu> <5mog0g5rva.fsf@jtc.redback.com>
X-SW-Source: 2000-10/msg00137.html
Content-length: 6599

Hi jtc.

Thanks for your reply.

jtc@redback.com wrote:

> >>>>> "Till" == Till Straumann <strauman@SLAC.Stanford.EDU> writes:
> Till> As of Version 5.4, WindRiver has more or less silently removed
> Till> support for the RDB protocol. This means that the gdb target
> Till> `vxworks' no longer works with VxWorks versions later than 5.3
>
> Till> However, there is another server on the vxWorks target talking a
> Till> different protocol, WDB, which at least is quite well documented.
>
> It's OK, but at least in the copy of the WDB spec I have there are
> some holes, such as in what set and at what offset each register is
> located for the get/fetch register commands.

Our Tornado docs (that came with Tornado II/ vxWorks 5.4 for NT [:-(]
provide a chapter about WDB that is quite extensive (though not complete
when it comes to nasty details). But they state e.g. that the register
commands
get/send an image of a REG_SET / FPREG_SET structure. In fact, this
was one of the easiest parts.

They even provide a header file, wdb.h, and sources for the xdr_XXX_YYY()
wrapper routines, which I am currently using. I figured that if someone
with the
FSF would talk to WRS, they perhaps would be willing to donate these
files (in the same way they donated vx-share).

> I wasn't able to find
> the WTX or WDB specs in the Tornado II documentation

Our docs cover WTX as well.

> We're using a WDB back end I hacked from Wind River's vxgdb sources
> remote-wtx.c module.  I've been meaning to re-write those bits so I
> could contribute it for the last year or so.  Unfortunately, it's a
> fairly low on my priority list.

I asked WRS for a copy of their gdb sources - no reply however. I decided
that
it would be faster and easier to implement the stuff by myself...

> If your code isn't similarly encumbered, and you're able to contribute
> it, it's probably a faster route to supplying WDB support to GDB users.

Well, it seems to work so far but it's still very new - the code would
have
to be shaked, of course.

>
> Till> I added support for WDB to `remote-vx.c' which means that gdb
> Till> can again talk to vxworks :-) The CPU dependent parts (a very
> Till> tiny piece of code) are currently only implemented for the
> Till> powerpc (I could easily add m68k, if there's any need).
>
> Did you maintain support for RDB in the process?  While WRS has
> dropped support for RDB, there may be vxworks users in the field that
> still use it.  We should continue to support it if at all possible.

Of course, RDB is still supported.
My code is included in the remote-vx.c file and is activated
by conditional compilation (the downside being that gdb can not support
both, RDB and WDB targets in one configuration). The WDB stuff was
not put into a separate file for two reasons:
     - some of the old code is also used for WDB.
     -  (I'm sorry to admit that I hate autoconf, configure, automake,
autowhatever
         I never had the time to properly learn it - I'd need some help
when it
         comes to change the Meta-Makefiles)

>
> If you kept RDB support, how much code for RDB and WDB are shared in
> remote-vx.c?  In our sources, remote-wdb is completely separate.

I guess that separating the WDB parts out of remote-vx.c
would not be too much trouble. However, some of the now `static' routines
would have to be exported from remote-vx.c. Depends also on whether
we want to support two different targets (RDB and WDB) in the same gdb
configuration.

>
> Till> Because WDB lacks some functionality that RDB had provided (on
> Till> the other hand, WDB adds new features), I also wrote a small
> Till> server which can be started on the target. This server
> Till> implements a subset of the RDB protocol, essentially the parts
> Till> which are necessary to remotely load files and lookup modules.
>
> When you talk about a "small server that can be started on the target",
> you're talking about something that runs on the vxWorks system, right?

Sure. I was thinking about how to implement the `load files', `get loaded
file information' etc. stuff. One possibility I envisioned was doing only
WDB calls.
However, because WDB (AFAIK) does not implement any load commands,
we would have to rely on vxWorks providing these services (i.e. the object
module loader).
I could have used the WDB_FUNC_CALL / WDB_DIRECT_CALL RPCs
to call e.g. `loadModuleAt'. However, passing parameters and return values

back and forth would have been quite cumbersome (need to allocate
memory on the target, copy its contents to the host and free the memory
again, catch errors, cleanup etc.).

I decided that it was much easier to implement a simple server
(350 lines of code) which does the VX_FP_INQUIRE, VX_BOOT_FILE_INQ,
VX_STATE_INQ and VX_LOAD command subset of RDB.  (The related gdb
client side parts needed no change at all). Of course, an alternative
would have been
to implement a full-fledged RDB server - however, implementing
breakpoints would have been much more difficult than letting the WDB agent

do the job. Hence the dual-protocol approach.

Note that it is not necessary to run my RDB server - gdb will still
work (with reduced functionality). Thus, it is also possible to
debug standalone applications which have WDB but no module loader
support. In this case, you must tell gdb which kernel image file to
read symbol information from.

> Another engineer here hacked code into my remote-wdb.c to support
> remotely loading files, but it works entirely with WDB.  Can you
> please explain more?

(see above)

How does your implementation work; can you explain more?

> We also have a WDB multiplexor so that multiple GDBs, each connected
> to a single vxWorks task, can debug a system.

Yeah, an important issue - however, I do not have a solution yet. Is your
multiplexor integrated in the gdb backend or independent? Is it available
to the public?

Of course, my tiny-RDB  server would have to be multi-connection capable,
too but this is easy.

>
>         --jtc

BTW: what's your name?

IMHO, my code has two goodies:

        target vxworks <target-ip>  <kernel-file>

the `target' command lets you specify the kernel image path
(useful if the local path and the remote path are not identical).
This extra parameter must be specified if tiny-RDB is not running.

        attach 0

attaches the debugger to the task that first hits any enabled
breakpoint.  (It's sometimes not possible to know which task
will run the piece of code you want to debug. This new feature
will catch it).

--- Till

PS: remember that I'm not on this list, please CC to my personal
address.