[PATCH] dejagnu framework for testing gdbserver

[Michael Snyder <msnyder@redhat.com>]

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;