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

[Pedro Alves <palves at redhat dot com>]

On 04/13/2016 09:52 PM, Orgad Shaneh wrote:
> On Wed, Apr 13, 2016 at 11:27 PM, Pedro Alves <palves@redhat.com> wrote:

>> So there's no xml target description involved?  It sounds like
>> either the default layout or some of the mips_register_g_packet_guesses
>> guesses is taking effect then.
>>
>> If the size of the register file gdbserver is sending is larger than
>> what gdb is expecting, then it's possible to register offsets
>> are mismatched as well.
>>
>> Figure out what set of registers gdbserver is sending, and compare to
>> "maint print remote-registers", after connecting.  What's the mismatch?
> 
> See the attached files.
> 
> gdb-local-6.5 is a local execution of gdb on the target machine.
> gdb-remote-7.4 is the output of 7.4 official version (without Cavium
> patches), which works.
> gdb-remote-7.6 is the output of 7.6 Cavium version, which doesn't.
> 

Bah, mips uses masking pseudo registers for all registers, so 
"maint print remote-registers" doesn't show the registers' names.

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.

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.
git blame points at around the initial mips linux gdbserver
submission:

 https://sourceware.org/ml/gdb-patches/2006-11/msg00057.html

That's 6.6 era, not 7.6..

So it may be this guessing mechanism is broken.  If so, that's where the
fixing should be aimed at.  If not, well, we should figure out more.

> gdb-remote-7.6 is the output of 7.6 Cavium version, which doesn't.

TBC, does this happen with current FSF master against old (unpatched)
FSF 7.4 gdbserver?  This might be due to local Cavium patches...

Thanks,
Pedro Alves