This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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: gdb-remote-all-registers-7.4.txt
Description: Text document

Attachment: gdb-local-all-registers-6.5.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]