This is the mail archive of the gdb-patches@sourceware.cygnus.com 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]

Patch to speed up remote protocol


The remote protocol code always retrieves all the register values
before it stores a register value.  That is required for older stubs,
but it is a waste of time if the stub supports the 'P' request, which
permits the protocol to set a specific register.

This is particularly unfortunate because gdb likes to write the PC
every time it continues, which means that when stepping through a
program, gdb is continually and uselessly fetching all the register
values, with horrible results over a slow serial line.

This patch fixes this problem by skipping the fetch of all the
register values when the 'P' request is known to work.

Ian


1998-10-21  Ian Lance Taylor  <ian@airs.com>

	* remote.c (stub_definitely_supports_P): New static variable.
	(remote_open_1): Initialize stub_definitely_supports_P.
	(remote_prepare_to_store): Only call read_register_bytes if not
	stub_definitely_supports_P.
	(remote_store_registers): Set stub_definitely_supports_P.


Index: remote.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/remote.c,v
retrieving revision 1.1.1.7
diff -u -p -r1.1.1.7 remote.c
--- remote.c	1999/06/28 16:00:51	1.1.1.7
+++ remote.c	1999/07/02 20:07:12
@@ -444,6 +444,10 @@ static int remote_register_buf_size = 0;
    doesn't support 'P', the only consequence is some unnecessary traffic.  */
 static int stub_supports_P = 1;
 
+/* This is set if the stub definitely supports the 'P' request.  This
+   can be used to speed up remote_prepare_to_store.  */
+static int stub_definitely_supports_P = 0;
+
 /* These are pointers to hook functions that may be set in order to
    modify resume/wait behavior for a particular architecture.  */
 
@@ -1669,6 +1673,7 @@ serial device is attached to the remote 
      switches from one stub to another, we can (if the target is
      closed and reopened) cope.  */
   stub_supports_P = 1;
+  stub_definitely_supports_P = 0;
 
   general_thread  = -2;
   continue_thread = -2;
@@ -2199,7 +2204,8 @@ static void 
 remote_prepare_to_store ()
 {
   /* Make sure the entire registers array is valid.  */
-  read_register_bytes (0, (char *)NULL, REGISTER_BYTES);
+  if (! stub_definitely_supports_P)
+    read_register_bytes (0, (char *)NULL, REGISTER_BYTES);
 }
 
 /* Store register REGNO, or all registers if REGNO == -1, from the contents
@@ -2233,6 +2239,7 @@ remote_store_registers (regno)
       if (buf[0] != '\0')
 	{
 	  /* The stub understands the 'P' request.  We are done.  */
+	  stub_definitely_supports_P = 1;
 	  return;
 	}
 
@@ -2240,6 +2247,10 @@ remote_store_registers (regno)
 	 and don't try using 'P' in the future (it will just waste our
 	 time).  */
       stub_supports_P = 0;
+
+      /* If we got an earlier 'P' response, we may be in trouble now.  */
+      if (stub_definitely_supports_P)
+	error ("Protocol error: P worked earlier, but failed now");
     }
 
   buf[0] = 'G';

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