From: Orgad Shaneh <orgads@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Luis Machado <lgustavo@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
Date: Thu, 14 Apr 2016 08:33:00 -0000 [thread overview]
Message-ID: <CAGHpTB+y=1Rst7H9BsSX_enxraXAy_YpzPYRSCfoa=8QXvEM-w@mail.gmail.com> (raw)
In-Reply-To: <570EC0C0.8030500@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4031 bytes --]
On Thu, Apr 14, 2016 at 12:57 AM, Pedro Alves <palves@redhat.com> wrote:
> 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.
Output attached.
>
> 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.
Interesting...
>
> 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.
Can you suggest a fix or a workaround?
>> 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...
No. It works as expected.
I tried compiling FSF 6.5 for mips64-octeon-linux-gnu host,
configured using ./configure --host=mips64-octeon-linux-gnu
--target=mips64-octeon-linux-gnu
It works fine with 7.4, but uses the host's gcc with 6.5...
[-- Attachment #2: gdb-remote-all-registers-7.4.txt --]
[-- Type: text/plain, Size: 3428 bytes --]
(gdb) info all-registers
zero at v0 v1
R0 0000000000000000 0000000000000000 0000000000000000 0000000000000000
a0 a1 a2 a3
R4 0000000000000000 0000000000000000 0000000000000000 0000000000000000
a4 a5 a6 a7
R8 0000000000000000 0000000000000000 0000000000000000 0000000000000000
t0 t1 t2 t3
R12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
s0 s1 s2 s3
R16 0000000000000000 00000055559e2bb8 000000ffff82ec88 000000ffff82ee47
s4 s5 s6 s7
R20 0000000120264b98 0000000000000000 0000000000000003 0000000000000000
t8 t9 k0 k1
R24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
gp sp s8 ra
R28 0000000000000000 000000ffffe72ca0 000000ffffff2f45 0000000000000000
sr lo hi bad
0000000000000000 0000000000001b41 00000000000002e7 00000055557980a8
cause pc
0000000000800020 0000005555557c50
f0: 0xffffffffffffffff flt: -nan dbl: -nan
f1: 0xffffffffffffffff flt: -nan dbl: -nan
f2: 0xffffffffffffffff flt: -nan dbl: -nan
f3: 0xffffffffffffffff flt: -nan dbl: -nan
f4: 0xffffffffffffffff flt: -nan dbl: -nan
f5: 0xffffffffffffffff flt: -nan dbl: -nan
f6: 0xffffffffffffffff flt: -nan dbl: -nan
f7: 0xffffffffffffffff flt: -nan dbl: -nan
f8: 0xffffffffffffffff flt: -nan dbl: -nan
f9: 0xffffffffffffffff flt: -nan dbl: -nan
f10: 0xffffffffffffffff flt: -nan dbl: -nan
f11: 0xffffffffffffffff flt: -nan dbl: -nan
f12: 0xffffffffffffffff flt: -nan dbl: -nan
f13: 0xffffffffffffffff flt: -nan dbl: -nan
f14: 0xffffffffffffffff flt: -nan dbl: -nan
f15: 0xffffffffffffffff flt: -nan dbl: -nan
f16: 0xffffffffffffffff flt: -nan dbl: -nan
f17: 0xffffffffffffffff flt: -nan dbl: -nan
f18: 0xffffffffffffffff flt: -nan dbl: -nan
f19: 0xffffffffffffffff flt: -nan dbl: -nan
f20: 0xffffffffffffffff flt: -nan dbl: -nan
f21: 0xffffffffffffffff flt: -nan dbl: -nan
f22: 0xffffffffffffffff flt: -nan dbl: -nan
f23: 0xffffffffffffffff flt: -nan dbl: -nan
f24: 0xffffffffffffffff flt: -nan dbl: -nan
f25: 0xffffffffffffffff flt: -nan dbl: -nan
f26: 0xffffffffffffffff flt: -nan dbl: -nan
f27: 0xffffffffffffffff flt: -nan dbl: -nan
f28: 0xffffffffffffffff flt: -nan dbl: -nan
f29: 0xffffffffffffffff flt: -nan dbl: -nan
f30: 0xffffffffffffffff flt: -nan dbl: -nan
f31: 0xffffffffffffffff flt: -nan dbl: -nan
fsr fir
00000000 00000000
[-- Attachment #3: gdb-local-all-registers-6.5.txt --]
[-- Type: text/plain, Size: 1458 bytes --]
(gdb) info all-registers
zero at v0 v1
R0 0000000000000000 fffffffffffffff0 00000055558df650 0000000000000000
a0 a1 a2 a3
R4 0000000000000001 000000ffffa44c88 000000ffffa44c98 000000ffffdb3f31
a4 a5 a6 a7
R8 00000055558e2d90 00000055555643f0 000000ffffa44c80 0000000000000000
t0 t1 t2 t3
R12 0000000000000000 00000055556722c0 ffffffff8021b468 0000000120000820
s0 s1 s2 s3
R16 0000005555671760 0000000000000000 0000000000000000 0000000120264b40
s4 s5 s6 s7
R20 0000000120264b40 0000000000000001 0000000000000002 0000000000000000
t8 t9 k0 k1
R24 0000000000000006 0000000120000910 0000005555574160 0000000000000000
gp sp s8 ra
R28 0000000000110000 000000ffffa44b30 000000ffffa44b30 00000055556a7298
sr lo hi bad
0000000000108cf3 0000000000005e17 00000000000001a5 00000055556be010
cause pc
0000000000800024 0000000120000928
next prev parent reply other threads:[~2016-04-14 8:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-10 14:49 Orgad Shaneh
2016-04-11 21:19 ` Luis Machado
2016-04-12 5:16 ` Orgad Shaneh
2016-04-12 13:37 ` Luis Machado
2016-04-13 5:43 ` Orgad Shaneh
2016-04-13 19:11 ` Luis Machado
2016-04-13 20:07 ` Orgad Shaneh
2016-04-13 20:27 ` Pedro Alves
2016-04-13 20:52 ` Orgad Shaneh
2016-04-13 21:57 ` Pedro Alves
2016-04-14 8:33 ` Orgad Shaneh [this message]
2016-04-14 9:07 ` Orgad Shaneh
2016-04-14 9:22 ` Pedro Alves
2016-04-14 9:39 ` Orgad Shaneh
2016-04-14 9:47 ` Pedro Alves
2016-04-14 21:21 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGHpTB+y=1Rst7H9BsSX_enxraXAy_YpzPYRSCfoa=8QXvEM-w@mail.gmail.com' \
--to=orgads@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox