This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Orgad Shaneh <orgads at gmail dot com>, Luis Machado <lgustavo at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Thu, 14 Apr 2016 22:20:49 +0100
- Subject: Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
- Authentication-results: sourceware.org; auth=none
- References: <CAGHpTBJLq0RhLo=tTP_BmDzNAaVFCHebBvoom21x-ETT9t4ZQw at mail dot gmail dot com> <570C14D4 dot 3030600 at codesourcery dot com> <CAGHpTBLM5r5xVWzxYv=qZpRz_o-d9=gp_yg+RSYqoEXFBywgfQ at mail dot gmail dot com> <570CFA04 dot 3070109 at codesourcery dot com> <CAGHpTBKTr=DcosvWbObCpFPGjNqgMqhQwBgRn3MOz6voBLGkkw at mail dot gmail dot com> <570E99DC dot 8080902 at codesourcery dot com> <CAGHpTB+dZ3a86nFFN8CAyTxzTBMk6eReWZpg03HYVqQO8-TVyA at mail dot gmail dot com> <570EABAA dot 50908 at redhat dot com> <CAGHpTB+zOJwfNaWjsvWTu9ek7qpgdNC1KOR336zN09uySJ9Bew at mail dot gmail dot com> <570EC0C0 dot 8030500 at redhat dot 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