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: Pedro Alves <palves at redhat dot com>
- To: Orgad Shaneh <orgads at gmail dot com>
- Cc: Luis Machado <lgustavo at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Wed, 13 Apr 2016 22:57:20 +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>
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