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

Maciej W. Rozycki
2016-04-14T21:21:13Z

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