Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message

["Maciej W. Rozycki" <macro@imgtec.com>]

On Wed, 13 Apr 2016, Pedro Alves wrote:

> However, we can see that gdb 7.4 expects more registers, as expected, and
> that it expects registers up till register 89:
>  
> ...
>  ''           88   88    704       8 int64_t              88         704
>  ''           89   89    712       8 int64_t              89         712
> ...
> 
> while 7.6 expects registers up till register number 78:
> 
> ...
>  ''           77   77    616       8 int64_t              77         616
>  ''           78   78    624       8 int64_t              78         624
> ...
> 
> I'd compare "info all-registers" to paint a more complete picture.
> 
> Looking at current master's mips-tdep.c, we see:
> 
> static struct gdbarch *
> mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> {
> ...
>   else if (info.osabi == GDB_OSABI_LINUX)
>     {
> ...
>       num_regs = 79;
> ...
>     }
>   else
>     {
>       num_regs = MIPS_LAST_EMBED_REGNUM + 1;
> ...
>     }
> ...
> 
> And in mips-tdep.h, we see:
> 
> ...
>   MIPS_LAST_EMBED_REGNUM = 89	/* Last one.  */
> ...
> 
> So, bingo, it seems?  Old gdbserver is sending the embedded layout,
> while newer gdb expects the linux-specific layout.

 I agree this is the reason of the failure.

> In current master we have:
> 
> static void
> mips_register_g_packet_guesses (struct gdbarch *gdbarch)
> {
>   /* If the size matches the set of 32-bit or 64-bit integer registers,
>      assume that's what we've got.  */
>   register_remote_g_packet_guess (gdbarch, 38 * 4, mips_tdesc_gp32);
>   register_remote_g_packet_guess (gdbarch, 38 * 8, mips_tdesc_gp64);
> 
>   /* If the size matches the full set of registers GDB traditionally
>      knows about, including floating point, for either 32-bit or
>      64-bit, assume that's what we've got.  */
>   register_remote_g_packet_guess (gdbarch, 90 * 4, mips_tdesc_gp32);
>   register_remote_g_packet_guess (gdbarch, 90 * 8, mips_tdesc_gp64);
> 
>   /* Otherwise we don't have a useful guess.  */
> }
> 
> 
> Specifically, the:
> 
>  register_remote_g_packet_guess (gdbarch, 90 * 8, mips_tdesc_gp64);
> 
> line should match this.  So seems like this _should_ be working.

 Nope, the culprit is here:

  /* Record the maximum possible size of the g packet - it may turn out
     to be smaller.  */
  rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs);

and then in `map_regcache_remote_table':

  for (regnum = 0; regnum < gdbarch_num_regs (gdbarch); regnum++)

-- so for a non-described Linux target `sizeof_g_packet' is initially 
capped at (79 * 8) and cannot be grown to (90 * 8) as the first `g' reply 
is seen, because growing is not allowed in the remote target.

 So it's:

commit 1faeff088bbbd037d7769d214378b4faf805fa2e
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Thu Mar 1 22:19:48 2012 +0000

which needs fixing, as you've correctly identified in a later reply.

 I think I know what to do there and I'll post a proposed fix shortly.

 NB this is not related to PR gdb/13984 as that bug report is about the 
x86-64 target.

  Maciej