'g' packet reply is too long error when target changes number of registers

["alexandru.sardan@freescale.com" <alexandru.sardan@freescale.com>]

Hello,

I'm trying to debug an ARM Aarch64 target with gdb-cross and I get a
'g' packet reply is too long error in the following scenario:

* I debug my ARM target through a probe that has a gdbserver running on it
(gdbproxy).
* First I load a custom target description in gdb that reflects the current 
hardware I am debugging
* I connect to the probe with "target remote probe_ip"
* Then I configure the probe to connect to the target (using the same target
description as the one loaded in GDB)
* When I ask for the register Info (info reg), I get the 'g' packet reply 
error.

Because the probe had no knowledge of the target that will be debugged 
beforehand, the "target remote" command will force the probe to reply with 
info about a smaller number of registers (according to the default description)
than gdb expects.
This causes rsa->sizeof_g_packet to be reduced.

After configuration, the probe will send all the register information of the 
target. This causes the 'g'packet reply error because now, more registers 
are being sent.

Why is rsa->sizeof_g_packet shrunk when a smaller packet is received.
Shouldn't this reflect the size in accordance with the target description?

I've made a small patch to address this issue. Do you think it's a proper fix?


Kind regards,
Alex


Patch follows:

From 8cae18e62d544094b160878459624605c0491534 Mon Sep 17 00:00:00 2001
From: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Date: Tue, 21 Jan 2014 17:45:20 +0200
Subject: [PATCH] Fix remote 'g' packet reply is too long error

Fix remote 'g' packet reply is too long error
when target architecture is modified.
As long as the target description is the same as
the hardware, this error will no longer appeear

Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
---
 gdb/remote.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index 7761e00..c29d88a 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -6103,7 +6103,7 @@ process_g_packet (struct regcache *regcache)
   struct gdbarch *gdbarch = get_regcache_arch (regcache);
   struct remote_state *rs = get_remote_state ();
   struct remote_arch_state *rsa = get_remote_arch_state ();
-  int i, buf_len;
+  int i, buf_len, reg_pack_sz;
   char *p;
   char *regs;
 
@@ -6125,31 +6125,33 @@ process_g_packet (struct regcache *regcache)
      the 'p' packet must be used.  */
   if (buf_len < 2 * rsa->sizeof_g_packet)
     {
-      rsa->sizeof_g_packet = buf_len / 2;
+      reg_pack_sz = buf_len / 2;
 
       for (i = 0; i < gdbarch_num_regs (gdbarch); i++)
 	{
 	  if (rsa->regs[i].pnum == -1)
 	    continue;
 
-	  if (rsa->regs[i].offset >= rsa->sizeof_g_packet)
+	  if (rsa->regs[i].offset >= reg_pack_sz )
 	    rsa->regs[i].in_g_packet = 0;
 	  else
 	    rsa->regs[i].in_g_packet = 1;
 	}
     }
+  else
+      reg_pack_sz = rsa->sizeof_g_packet;
 
-  regs = alloca (rsa->sizeof_g_packet);
+  regs = alloca (reg_pack_sz);
 
   /* Unimplemented registers read as all bits zero.  */
-  memset (regs, 0, rsa->sizeof_g_packet);
+  memset (regs, 0, reg_pack_sz);
 
   /* Reply describes registers byte by byte, each byte encoded as two
      hex characters.  Suck them all up, then supply them to the
      register cacheing/storage mechanism.  */
 
   p = rs->buf;
-  for (i = 0; i < rsa->sizeof_g_packet; i++)
+  for (i = 0; i < reg_pack_sz; i++)
     {
       if (p[0] == 0 || p[1] == 0)
 	/* This shouldn't happen - we adjusted sizeof_g_packet above.  */
-- 
1.7.9.5