* PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
@ 2016-04-10 14:49 Orgad Shaneh
2016-04-11 21:19 ` Luis Machado
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-10 14:49 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 100 bytes --]
Please review the attached patch. It was inspired by the patch
attached to the bug report.
Thanks.
[-- Attachment #2: 0001-PR13984-gdb-stops-controlling-a-thread.patch --]
[-- Type: application/octet-stream, Size: 1413 bytes --]
From 03ab95933b85dd85c2f4fa5797017e6cee0c8466 Mon Sep 17 00:00:00 2001
From: Orgad Shaneh <orgad.shaneh@audiocodes.com>
Date: Sun, 10 Apr 2016 17:39:24 +0300
Subject: [PATCH] PR13984, gdb stops controlling a thread...
... after "Remote 'g' packet reply is too long: ..." error message
PR13984:
remote.c: Handle long g packets instead of failing
---
gdb/remote.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/gdb/remote.c b/gdb/remote.c
index 5c407b6..e8951dc 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -7188,10 +7188,6 @@ process_g_packet (struct regcache *regcache)
buf_len = strlen (rs->buf);
- /* Further sanity checks, with knowledge of the architecture. */
- if (buf_len > 2 * rsa->sizeof_g_packet)
- error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
-
/* Save the size of the packet sent to us by the target. It is used
as a heuristic when determining the max size of packets that the
target can safely receive. */
@@ -7202,7 +7198,7 @@ process_g_packet (struct regcache *regcache)
update our records. A 'g' reply that doesn't include a register's
value implies either that the register is not available, or that
the 'p' packet must be used. */
- if (buf_len < 2 * rsa->sizeof_g_packet)
+ if (buf_len != 2 * rsa->sizeof_g_packet)
{
rsa->sizeof_g_packet = buf_len / 2;
--
2.8.0.windows.1
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-10 14:49 PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message Orgad Shaneh
@ 2016-04-11 21:19 ` Luis Machado
2016-04-12 5:16 ` Orgad Shaneh
0 siblings, 1 reply; 16+ messages in thread
From: Luis Machado @ 2016-04-11 21:19 UTC (permalink / raw)
To: Orgad Shaneh, gdb-patches
Hi,
On 04/10/2016 09:49 AM, Orgad Shaneh wrote:
> Please review the attached patch. It was inspired by the patch
> attached to the bug report.
Usually, when you receive that message from GDB it because your target
reported an incorrect register set as a 'g' reply.
The correct solution is to fix your remote target to reply the proper
register set.
From the description, it sounds like QEMU needs to be adjusted.
>
> Thanks.
>
>
> 0001-PR13984-gdb-stops-controlling-a-thread.patch
>
>
> From 03ab95933b85dd85c2f4fa5797017e6cee0c8466 Mon Sep 17 00:00:00 2001
> From: Orgad Shaneh<orgad.shaneh@audiocodes.com>
> Date: Sun, 10 Apr 2016 17:39:24 +0300
> Subject: [PATCH] PR13984, gdb stops controlling a thread...
>
> ... after "Remote 'g' packet reply is too long: ..." error message
>
> PR13984:
> remote.c: Handle long g packets instead of failing
> ---
> gdb/remote.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/gdb/remote.c b/gdb/remote.c
> index 5c407b6..e8951dc 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -7188,10 +7188,6 @@ process_g_packet (struct regcache *regcache)
>
> buf_len = strlen (rs->buf);
>
> - /* Further sanity checks, with knowledge of the architecture. */
> - if (buf_len > 2 * rsa->sizeof_g_packet)
> - error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
> -
This is a serious error. If GDB fetches a bogus register set reply, it
will most definitely do the wrong thing after this.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-11 21:19 ` Luis Machado
@ 2016-04-12 5:16 ` Orgad Shaneh
2016-04-12 13:37 ` Luis Machado
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-12 5:16 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb-patches
Hi,
On Tue, Apr 12, 2016 at 12:19 AM, Luis Machado
<lgustavo@codesourcery.com> wrote:
> Hi,
>
> On 04/10/2016 09:49 AM, Orgad Shaneh wrote:
>>
>> Please review the attached patch. It was inspired by the patch
>> attached to the bug report.
>
>
> Usually, when you receive that message from GDB it because your target
> reported an incorrect register set as a 'g' reply.
>
> The correct solution is to fix your remote target to reply the proper
> register set.
>
> From the description, it sounds like QEMU needs to be adjusted.
>
Thanks for your reply.
I don't use QEMU. I did not describe my use case in the bug report,
did just now.
I got this message when I tried to remotely debug a
mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
and the debugger stops functioning.
The proposed patch fixes this issue for me.
Using a newer gdbserver (Cavium SDK3 comes with 7.6) might also be a
solution, but we need to support the old one as well.
>>
>> Thanks.
>>
>>
>> 0001-PR13984-gdb-stops-controlling-a-thread.patch
>>
>>
>> From 03ab95933b85dd85c2f4fa5797017e6cee0c8466 Mon Sep 17 00:00:00 2001
>> From: Orgad Shaneh<orgad.shaneh@audiocodes.com>
>> Date: Sun, 10 Apr 2016 17:39:24 +0300
>> Subject: [PATCH] PR13984, gdb stops controlling a thread...
>>
>> ... after "Remote 'g' packet reply is too long: ..." error message
>>
>> PR13984:
>> remote.c: Handle long g packets instead of failing
>> ---
>> gdb/remote.c | 6 +-----
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/gdb/remote.c b/gdb/remote.c
>> index 5c407b6..e8951dc 100644
>> --- a/gdb/remote.c
>> +++ b/gdb/remote.c
>> @@ -7188,10 +7188,6 @@ process_g_packet (struct regcache *regcache)
>>
>> buf_len = strlen (rs->buf);
>>
>> - /* Further sanity checks, with knowledge of the architecture. */
>> - if (buf_len > 2 * rsa->sizeof_g_packet)
>> - error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
>> -
>
>
> This is a serious error. If GDB fetches a bogus register set reply, it will
> most definitely do the wrong thing after this.
Possibly, but doing "something wrong" is likely to be better than just
quitting. Maybe we should leave the warning, but still correct the
values used.
- Orgad
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-12 5:16 ` Orgad Shaneh
@ 2016-04-12 13:37 ` Luis Machado
2016-04-13 5:43 ` Orgad Shaneh
0 siblings, 1 reply; 16+ messages in thread
From: Luis Machado @ 2016-04-12 13:37 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: gdb-patches
On 04/12/2016 12:16 AM, Orgad Shaneh wrote:
> Hi,
>
> On Tue, Apr 12, 2016 at 12:19 AM, Luis Machado
> <lgustavo@codesourcery.com> wrote:
>> Hi,
>>
>> On 04/10/2016 09:49 AM, Orgad Shaneh wrote:
>>>
>>> Please review the attached patch. It was inspired by the patch
>>> attached to the bug report.
>>
>>
>> Usually, when you receive that message from GDB it because your target
>> reported an incorrect register set as a 'g' reply.
>>
>> The correct solution is to fix your remote target to reply the proper
>> register set.
>>
>> From the description, it sounds like QEMU needs to be adjusted.
>>
>
> Thanks for your reply.
>
> I don't use QEMU. I did not describe my use case in the bug report,
> did just now.
>
I got that from the bug report.
> I got this message when I tried to remotely debug a
> mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
>
> GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
> and the debugger stops functioning.
>
I suppose GDB 7.5 is slightly incompatible with older gdbserver versions.
What kind of target description does gdbserver return in this case (set
debug remote 1)?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-12 13:37 ` Luis Machado
@ 2016-04-13 5:43 ` Orgad Shaneh
2016-04-13 19:11 ` Luis Machado
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-13 5:43 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
>> I got this message when I tried to remotely debug a
>> mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
>>
>> GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
>> and the debugger stops functioning.
>>
>
> I suppose GDB 7.5 is slightly incompatible with older gdbserver versions.
>
> What kind of target description does gdbserver return in this case (set
> debug remote 1)?
Full log attached. Thanks for your help.
- Orgad
[-- Attachment #2: gdb.log --]
[-- Type: application/octet-stream, Size: 43535 bytes --]
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=mips64-octeon-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set debug remote 1
(gdb) file D:/target.elf
Reading symbols from D:\target.elf...done.
(gdb) target remote tcp:10.33.9.60:10000
Remote debugging using tcp:10.33.9.60:10000
Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
Packet received:
Packet qSupported (supported-packets) is NOT supported
Sending packet: $Hg0#df...Ack
Packet received: E01
Sending packet: $?#3f...Ack
Packet received: T0525:000000002b6d7654;1d:000000007fbc39f0;
Sending packet: $Hc-1#09...Ack
Packet received: E01
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qAttached#8f...Ack
Packet received:
Packet qAttached (query-attached) is NOT supported
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $Hg0#df...Ack
Packet received: E01
Sending packet: $g#67...Ack
Packet received: 0000000000000000ffffffff8057000000000000000002040000000000000000000000007fbc3a50000000007fbc3a50000000002aac4c9000000000000
000010000000000000003000000007fbc39c00000000000000003000000000000000300000000000000000000000000008c00a800000412afc000a800000412afc0000000000
000000001000000007fbc3a5800000000000000000000000000020000000000007fbc3ad8000000007fffffff000000007fffffff00000000000000000000000000000000000
000002b71eb9000000000000000000000000000000000000000002b886980000000007fbc39f0000000ffffe27fb8000000002b6d7640000000000000000000000000002dc6c
00000000000000000000000002aac4cec0000000000800020000000002b6d7654fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000
Sending packet: $m10000208,4#58...Ack
Packet received: 131e1350
Sending packet: $m131e1350,4#90...Ack
Packet received: 2abc2a40
Sending packet: $m2abc2a44,4#20...Ack
Packet received: 2abc2a58
Sending packet: $m2abc2a58,14#56...Ack
Packet received: 000000002aabf180100001842aac233800000000
Sending packet: $m2aac2338,14#25...Ack
Packet received: 2abc30002aac23202abc31542aac26882abc2a58
Sending packet: $m2aac2320,4#eb...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2324,4#ef...Ack
Packet received: 33322f6c
Sending packet: $m2aac2328,4#f3...Ack
Packet received: 69627074
Sending packet: $m2aac232c,4#1e...Ack
Packet received: 68726561
Sending packet: $m2aac2330,4#ec...Ack
Packet received: 642e736f
Sending packet: $m2aac2334,4#f0...Ack
Packet received: 2e300000
Sending packet: $m2aac2688,14#2d...Ack
Packet received: 2acd90002aac26702acd90b42aac29d02aac2338
Sending packet: $m2aac2670,4#f3...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2674,4#f7...Ack
Packet received: 33322f6c
Sending packet: $m2aac2678,4#fb...Ack
Packet received: 69626e6c
Sending packet: $m2aac267c,4#26...Ack
Packet received: 2e736f2e
Sending packet: $m2aac2680,4#f4...Ack
Packet received: 31000000
Sending packet: $m2aac29d0,14#54...Ack
Packet received: 2ae1f0002aac29b82ae1f1342aac2d202aac2688
Sending packet: $m2aac29b8,4#29...Ack
Packet received: 2f6c6962
Sending packet: $m2aac29bc,4#54...Ack
Packet received: 33322f6c
Sending packet: $m2aac29c0,4#22...Ack
Packet received: 69626372
Sending packet: $m2aac29c4,4#26...Ack
Packet received: 7970742e
Sending packet: $m2aac29c8,4#2a...Ack
Packet received: 736f2e31
Sending packet: $m2aac29cc,4#55...Ack
Packet received: 00000000
Sending packet: $m2aac2d20,14#4d...Ack
Packet received: 2af4d0002aac2d082af4d1542aac30682aac29d0
Sending packet: $m2aac2d08,4#22...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2d0c,4#4d...Ack
Packet received: 33322f6c
Sending packet: $m2aac2d10,4#1b...Ack
Packet received: 69627274
Sending packet: $m2aac2d14,4#1f...Ack
Packet received: 2e736f2e
Sending packet: $m2aac2d18,4#23...Ack
Packet received: 31000000
Sending packet: $m2aac3068,14#26...Ack
Packet received: 2b0550002aac30502b0551342aac33c02aac2d20
Sending packet: $m2aac3050,4#ec...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3054,4#f0...Ack
Packet received: 33322f6c
Sending packet: $m2aac3058,4#f4...Ack
Packet received: 69627574
Sending packet: $m2aac305c,4#1f...Ack
Packet received: 696c2e73
Sending packet: $m2aac3060,4#ed...Ack
Packet received: 6f2e3100
Sending packet: $m2aac33c0,14#4e...Ack
Packet received: 2b1580002aac33a02b1580f42aac37182aac3068
Sending packet: $m2aac33a0,4#1b...Ack
Packet received: 2f757372
Sending packet: $m2aac33a4,4#1f...Ack
Packet received: 2f6c6962
Sending packet: $m2aac33a8,4#23...Ack
Packet received: 33322f6c
Sending packet: $m2aac33ac,4#4e...Ack
Packet received: 69627374
Sending packet: $m2aac33b0,4#1c...Ack
Packet received: 64632b2b
Sending packet: $m2aac33b4,4#20...Ack
Packet received: 2e736f2e
Sending packet: $m2aac33b8,4#24...Ack
Packet received: 36000000
Sending packet: $m2aac3718,14#28...Ack
Packet received: 2b34c0002aac37002b34c1342aac3a682aac33c0
Sending packet: $m2aac3700,4#ee...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3704,4#f2...Ack
Packet received: 33322f6c
Sending packet: $m2aac3708,4#f6...Ack
Packet received: 69626d2e
Sending packet: $m2aac370c,4#21...Ack
Packet received: 736f2e36
Sending packet: $m2aac3710,4#ef...Ack
Packet received: 00000000
Sending packet: $m2aac3a68,14#57...Ack
Packet received: 2b5250002aac3a482b5250d42aac3dc02aac3718
Sending packet: $m2aac3a48,4#24...Ack
Packet received: 2f757372
Sending packet: $m2aac3a4c,4#4f...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3a50,4#1d...Ack
Packet received: 33322f6c
Sending packet: $m2aac3a54,4#21...Ack
Packet received: 69626763
Sending packet: $m2aac3a58,4#25...Ack
Packet received: 635f732e
Sending packet: $m2aac3a5c,4#50...Ack
Packet received: 736f2e31
Sending packet: $m2aac3a60,4#1e...Ack
Packet received: 00000000
Sending packet: $m2aac3dc0,14#7f...Ack
Packet received: 2b63a0002aac3da82b63a1742abc25782aac3a68
Sending packet: $m2aac3da8,4#54...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3dac,4#7f...Ack
Packet received: 33322f6c
Sending packet: $m2aac3db0,4#4d...Ack
Packet received: 6962632e
Sending packet: $m2aac3db4,4#51...Ack
Packet received: 736f2e36
Sending packet: $m2aac3db8,4#55...Ack
Packet received: 00000000
Sending packet: $m2abc2578,14#2c...Ack
Packet received: 2aaa8000100001542aaa80f4000000002aac3dc0
Sending packet: $m10000154,4#58...Ack
Packet received: 2f6c6962
Sending packet: $m10000158,4#5c...Ack
Packet received: 33322f6c
Sending packet: $m1000015c,4#87...Ack
Packet received: 642e736f
Sending packet: $m10000160,4#55...Ack
Packet received: 2e310000
Sending packet: $m2abc2a40,4#1c...Ack
Packet received: 00000001
warning: Could not load shared library symbols for 10 libraries, e.g. /lib32/libpthread.so.0.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Sending packet: $m2abc2a44,4#20...Ack
Packet received: 2abc2a58
Sending packet: $m2abc2a48,4#24...Ack
Packet received: 2aab5398
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Sending packet: $m2b6d7654,4#d1...Ack
Packet received: ffa20040
Sending packet: $m2b6d7650,4#cd...Ack
Packet received: 0000000c
Sending packet: $m2b6d764c,4#ff...Ack
Packet received: 24021792
Sending packet: $m2b6d7654,4#d1...Ack
Packet received: ffa20040
0x2b6d7654 in ?? ()
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:6e70746c5f76657273696f6e
Packet qSymbol (symbol-lookup) is supported
Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received:
(gdb) set sysroot D:/sysroot/octeon17
Reading symbols from D:/sysroot/octeon17/lib32/libpthread.so.0...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:6e70746c5f76657273696f6e
Sending packet: $qSymbol:2abd4538:6e70746c5f76657273696f6e#7a...Ack
Packet received: qSymbol:5f5f6e70746c5f746872656164735f6576656e7473
Sending packet: $qSymbol:2acd83e0:5f5f6e70746c5f746872656164735f6576656e7473#c2...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f74645f7468725f6576656e74735f74
Sending packet: $qSymbol:2abd4914:5f7468726561645f64625f73697a656f665f74645f7468725f6576656e74735f74#2c...Ack
Packet received: qSymbol:5f7468726561645f64625f74645f7468725f6576656e74735f745f6576656e745f62697473
Sending packet: $qSymbol:2abd4800:5f7468726561645f64625f74645f7468725f6576656e74735f745f6576656e745f62697473#d2...Ack
Packet received: qSymbol:5f5f6e70746c5f6372656174655f6576656e74
Sending packet: $qSymbol:2abc7890:5f5f6e70746c5f6372656174655f6576656e74#c0...Ack
Packet received: qSymbol:5f5f737461636b5f75736572
Sending packet: $qSymbol:2acd83d0:5f5f737461636b5f75736572#6c...Ack
Packet received: qSymbol:5f7468726561645f64625f6c6973745f745f6e657874
Sending packet: $qSymbol:2abd47e0:5f7468726561645f64625f6c6973745f745f6e657874#33...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6c697374
Sending packet: $qSymbol:2abd4720:5f7468726561645f64625f707468726561645f6c697374#ff...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f70746872656164
Sending packet: $qSymbol:2abd4910:5f7468726561645f64625f73697a656f665f70746872656164#07...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f7363686564706f6c696379
Sending packet: $qSymbol:2abd4770:5f7468726561645f64625f707468726561645f7363686564706f6c696379#21...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f7363686564706172616d5f73636865645f7072696f72697479
Sending packet: $qSymbol:2abd4780:5f7468726561645f64625f707468726561645f7363686564706172616d5f73636865645f7072696f72697479#50...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f7370656369666963
Sending packet: $qSymbol:2abd4790:5f7468726561645f64625f707468726561645f7370656369666963#81...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f746964
Sending packet: $qSymbol:2abd4740:5f7468726561645f64625f707468726561645f746964#68...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f63616e63656c68616e646c696e67
Sending packet: $qSymbol:2abd4760:5f7468726561645f64625f707468726561645f63616e63656c68616e646c696e67#e8...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f7265706f72745f6576656e7473
Sending packet: $qSymbol:2abd4730:5f7468726561645f64625f707468726561645f7265706f72745f6576656e7473#1c...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f73746172745f726f7574696e65
Sending packet: $qSymbol:2abd4750:5f7468726561645f64625f707468726561645f73746172745f726f7574696e65#21...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6576656e746275665f6576656e746d61736b5f6576656e745f62697473
Sending packet: $qSymbol:2abd47c0:5f7468726561645f64625f707468726561645f6576656e746275665f6576656e746d61736b5f6576656e745f62697473#ee...Ack
Packet received: qSymbol:5f5f6e70746c5f696e697469616c5f7265706f72745f6576656e7473
Sending packet: $qSymbol:2acd63c0:5f5f6e70746c5f696e697469616c5f7265706f72745f6576656e7473#6f...Ack
Packet received: qSymbol:5f7468726561645f64625f5f5f6e70746c5f696e697469616c5f7265706f72745f6576656e7473
Sending packet: $qSymbol:2abd4850:5f7468726561645f64625f5f5f6e70746c5f696e697469616c5f7265706f72745f6576656e7473#64...Ack
Packet received: qSymbol:737461636b5f75736564
Sending packet: $qSymbol:2acd6020:737461636b5f75736564#00...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6576656e74627566
Sending packet: $qSymbol:2abd47a0:5f7468726561645f64625f707468726561645f6576656e74627566#da...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6576656e746275665f6576656e746d61736b
Sending packet: $qSymbol:2abd47b0:5f7468726561645f64625f707468726561645f6576656e746275665f6576656e746d61736b#c2...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6e6578746576656e74
Sending packet: $qSymbol:2abd47d0:5f7468726561645f64625f707468726561645f6e6578746576656e74#7d...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f6c6973745f74
Sending packet: $qSymbol:2abd4914:5f7468726561645f64625f73697a656f665f6c6973745f74#09...Ack
Packet received: qSymbol:5f7468726561645f64625f6c6973745f745f70726576
Sending packet: $qSymbol:2abd47f0:5f7468726561645f64625f6c6973745f745f70726576#fc...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f74645f6576656e746275665f74
Sending packet: $qSymbol:2abd4918:5f7468726561645f64625f73697a656f665f74645f6576656e746275665f74#29...Ack
Packet received: qSymbol:5f7468726561645f64625f74645f6576656e746275665f745f6576656e746e756d
Sending packet: $qSymbol:2abd4810:5f7468726561645f64625f74645f6576656e746275665f745f6576656e746e756d#26...Ack
Packet received: qSymbol:5f7468726561645f64625f74645f6576656e746275665f745f6576656e7464617461
Sending packet: $qSymbol:2abd4820:5f7468726561645f64625f74645f6576656e746275665f745f6576656e7464617461#29...Ack
Packet received: qSymbol:5f5f6e70746c5f64656174685f6576656e74
Sending packet: $qSymbol:2abc7898:5f5f6e70746c5f64656174685f6576656e74#63...Ack
Packet received: qSymbol:5f5f6e70746c5f6e74687265616473
Sending packet: $qSymbol:2acd6010:5f5f6e70746c5f6e74687265616473#d6...Ack
Packet received: qSymbol:5f7468726561645f64625f5f5f6e70746c5f6e74687265616473
Sending packet: $qSymbol:2abd4830:5f7468726561645f64625f5f5f6e70746c5f6e74687265616473#fe...Ack
Packet received: qSymbol:5f5f6e70746c5f6c6173745f6576656e74
Sending packet: $qSymbol:2acd83e8:5f5f6e70746c5f6c6173745f6576656e74#4d...Ack
Packet received: qSymbol:5f7468726561645f64625f5f5f6e70746c5f6c6173745f6576656e74
Sending packet: $qSymbol:2abd4840:5f7468726561645f64625f5f5f6e70746c5f6c6173745f6576656e74#35...Ack
Packet received: qSymbol:5f5f707468726561645f6b657973
Sending packet: $qSymbol:2acd63d0:5f5f707468726561645f6b657973#45...Ack
Packet received: qSymbol:5f7468726561645f64625f5f5f707468726561645f6b657973
Sending packet: $qSymbol:2abd4860:5f7468726561645f64625f5f5f707468726561645f6b657973#3a...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f707468726561645f6b65795f737472756374
Sending packet: $qSymbol:2abd4914:5f7468726561645f64625f73697a656f665f707468726561645f6b65795f737472756374#32...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6b65795f7374727563745f736571
Sending packet: $qSymbol:2abd4870:5f7468726561645f64625f707468726561645f6b65795f7374727563745f736571#8c...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6b65795f7374727563745f6465737472
Sending packet: $qSymbol:2abd4880:5f7468726561645f64625f707468726561645f6b65795f7374727563745f6465737472#63...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f707468726561645f6b65795f64617461
Sending packet: $qSymbol:2abd4914:5f7468726561645f64625f73697a656f665f707468726561645f6b65795f64617461#57...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6b65795f646174615f736571
Sending packet: $qSymbol:2abd4890:5f7468726561645f64625f707468726561645f6b65795f646174615f736571#b3...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6b65795f646174615f64617461
Sending packet: $qSymbol:2abd48a0:5f7468726561645f64625f707468726561645f6b65795f646174615f64617461#41...Ack
Packet received: qSymbol:5f7468726561645f64625f73697a656f665f707468726561645f6b65795f646174615f6c6576656c32
Sending packet: $qSymbol:2abd491c:5f7468726561645f64625f73697a656f665f707468726561645f6b65795f646174615f6c6576656c32#fb...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f6b65795f646174615f6c6576656c325f64617461
Sending packet: $qSymbol:2abd48b0:5f7468726561645f64625f707468726561645f6b65795f646174615f6c6576656c325f64617461#b7...Ack
Packet received: qSymbol:5f7468726561645f64625f6c696e6b5f6d61705f6c5f746c735f6d6f646964
Sending packet: $qSymbol:2abd48c0:5f7468726561645f64625f6c696e6b5f6d61705f6c5f746c735f6d6f646964#63...Ack
Packet received: qSymbol:5f7468726561645f64625f6474765f647476
Sending packet: $qSymbol:2abd48d0:5f7468726561645f64625f6474765f647476#f4...Ack
Packet received: qSymbol:5f7468726561645f64625f6474765f745f706f696e7465725f76616c
Sending packet: $qSymbol:2abd48e0:5f7468726561645f64625f6474765f745f706f696e7465725f76616c#0d...Ack
Packet received: qSymbol:5f7468726561645f64625f707468726561645f64747670
Sending packet: $qSymbol:2abd4710:5f7468726561645f64625f707468726561645f64747670#ca...Ack
Packet received: qSymbol:5f7468726561645f64625f636f6e73745f7468726561645f61726561
Sending packet: $qSymbol:2abd4920:5f7468726561645f64625f636f6e73745f7468726561645f61726561#6f...Ack
Packet received: qSymbol:5f7468726561645f64625f72656769737465723634
Sending packet: $qSymbol::5f7468726561645f64625f72656769737465723634#a5...Ack
Packet received: qSymbol:5f7468726561645f64625f72656769737465723332
Sending packet: $qSymbol::5f7468726561645f64625f72656769737465723332#a0...Ack
Packet received: qSymbol:5f7468726561645f64625f726567697374657236345f7468726561645f61726561
Sending packet: $qSymbol::5f7468726561645f64625f726567697374657236345f7468726561645f61726561#fb...Ack
Packet received: qSymbol:5f7468726561645f64625f726567697374657233325f7468726561645f61726561
Sending packet: $qSymbol::5f7468726561645f64625f726567697374657233325f7468726561645f61726561#f6...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/libpthread.so.0
Reading symbols from D:/sysroot/octeon17/lib32/libnl.so.1...(no debugging symbols found)...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/libnl.so.1
Reading symbols from D:/sysroot/octeon17/lib32/libcrypt.so.1...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/libcrypt.so.1
Reading symbols from D:/sysroot/octeon17/lib32/librt.so.1...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/librt.so.1
Reading symbols from D:/sysroot/octeon17/lib32/libutil.so.1...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/libutil.so.1
Reading symbols from D:/sysroot/octeon17/usr/lib32/libstdc++.so.6...(no debugging symbols found)...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/usr/lib32/libstdc++.so.6
Reading symbols from D:/sysroot/octeon17/lib32/libm.so.6...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/libm.so.6
Reading symbols from D:/sysroot/octeon17/usr/lib32/libgcc_s.so.1...(no debugging symbols found)...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/usr/lib32/libgcc_s.so.1
Reading symbols from D:/sysroot/octeon17/lib32/libc.so.6...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/libc.so.6
Reading symbols from D:/sysroot/octeon17/lib32/ld.so.1...done.
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Loaded symbols for D:/sysroot/octeon17/lib32/ld.so.1
Sending packet: $m10000208,4#58...Ack
Packet received: 131e1350
Sending packet: $m131e1350,4#90...Ack
Packet received: 2abc2a40
Sending packet: $m2abc2a44,4#20...Ack
Packet received: 2abc2a58
Sending packet: $m2abc2a58,14#56...Ack
Packet received: 000000002aabf180100001842aac233800000000
Sending packet: $m2aac2338,14#25...Ack
Packet received: 2abc30002aac23202abc31542aac26882abc2a58
Sending packet: $m2aac2320,4#eb...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2324,4#ef...Ack
Packet received: 33322f6c
Sending packet: $m2aac2328,4#f3...Ack
Packet received: 69627074
Sending packet: $m2aac232c,4#1e...Ack
Packet received: 68726561
Sending packet: $m2aac2330,4#ec...Ack
Packet received: 642e736f
Sending packet: $m2aac2334,4#f0...Ack
Packet received: 2e300000
Sending packet: $m2aac2688,14#2d...Ack
Packet received: 2acd90002aac26702acd90b42aac29d02aac2338
Sending packet: $m2aac2670,4#f3...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2674,4#f7...Ack
Packet received: 33322f6c
Sending packet: $m2aac2678,4#fb...Ack
Packet received: 69626e6c
Sending packet: $m2aac267c,4#26...Ack
Packet received: 2e736f2e
Sending packet: $m2aac2680,4#f4...Ack
Packet received: 31000000
Sending packet: $m2aac29d0,14#54...Ack
Packet received: 2ae1f0002aac29b82ae1f1342aac2d202aac2688
Sending packet: $m2aac29b8,4#29...Ack
Packet received: 2f6c6962
Sending packet: $m2aac29bc,4#54...Ack
Packet received: 33322f6c
Sending packet: $m2aac29c0,4#22...Ack
Packet received: 69626372
Sending packet: $m2aac29c4,4#26...Ack
Packet received: 7970742e
Sending packet: $m2aac29c8,4#2a...Ack
Packet received: 736f2e31
Sending packet: $m2aac29cc,4#55...Ack
Packet received: 00000000
Sending packet: $m2aac2d20,14#4d...Ack
Packet received: 2af4d0002aac2d082af4d1542aac30682aac29d0
Sending packet: $m2aac2d08,4#22...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2d0c,4#4d...Ack
Packet received: 33322f6c
Sending packet: $m2aac2d10,4#1b...Ack
Packet received: 69627274
Sending packet: $m2aac2d14,4#1f...Ack
Packet received: 2e736f2e
Sending packet: $m2aac2d18,4#23...Ack
Packet received: 31000000
Sending packet: $m2aac3068,14#26...Ack
Packet received: 2b0550002aac30502b0551342aac33c02aac2d20
Sending packet: $m2aac3050,4#ec...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3054,4#f0...Ack
Packet received: 33322f6c
Sending packet: $m2aac3058,4#f4...Ack
Packet received: 69627574
Sending packet: $m2aac305c,4#1f...Ack
Packet received: 696c2e73
Sending packet: $m2aac3060,4#ed...Ack
Packet received: 6f2e3100
Sending packet: $m2aac33c0,14#4e...Ack
Packet received: 2b1580002aac33a02b1580f42aac37182aac3068
Sending packet: $m2aac33a0,4#1b...Ack
Packet received: 2f757372
Sending packet: $m2aac33a4,4#1f...Ack
Packet received: 2f6c6962
Sending packet: $m2aac33a8,4#23...Ack
Packet received: 33322f6c
Sending packet: $m2aac33ac,4#4e...Ack
Packet received: 69627374
Sending packet: $m2aac33b0,4#1c...Ack
Packet received: 64632b2b
Sending packet: $m2aac33b4,4#20...Ack
Packet received: 2e736f2e
Sending packet: $m2aac33b8,4#24...Ack
Packet received: 36000000
Sending packet: $m2aac3718,14#28...Ack
Packet received: 2b34c0002aac37002b34c1342aac3a682aac33c0
Sending packet: $m2aac3700,4#ee...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3704,4#f2...Ack
Packet received: 33322f6c
Sending packet: $m2aac3708,4#f6...Ack
Packet received: 69626d2e
Sending packet: $m2aac370c,4#21...Ack
Packet received: 736f2e36
Sending packet: $m2aac3710,4#ef...Ack
Packet received: 00000000
Sending packet: $m2aac3a68,14#57...Ack
Packet received: 2b5250002aac3a482b5250d42aac3dc02aac3718
Sending packet: $m2aac3a48,4#24...Ack
Packet received: 2f757372
Sending packet: $m2aac3a4c,4#4f...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3a50,4#1d...Ack
Packet received: 33322f6c
Sending packet: $m2aac3a54,4#21...Ack
Packet received: 69626763
Sending packet: $m2aac3a58,4#25...Ack
Packet received: 635f732e
Sending packet: $m2aac3a5c,4#50...Ack
Packet received: 736f2e31
Sending packet: $m2aac3a60,4#1e...Ack
Packet received: 00000000
Sending packet: $m2aac3dc0,14#7f...Ack
Packet received: 2b63a0002aac3da82b63a1742abc25782aac3a68
Sending packet: $m2aac3da8,4#54...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3dac,4#7f...Ack
Packet received: 33322f6c
Sending packet: $m2aac3db0,4#4d...Ack
Packet received: 6962632e
Sending packet: $m2aac3db4,4#51...Ack
Packet received: 736f2e36
Sending packet: $m2aac3db8,4#55...Ack
Packet received: 00000000
Sending packet: $m2abc2578,14#2c...Ack
Packet received: 2aaa8000100001542aaa80f4000000002aac3dc0
Sending packet: $m10000154,4#58...Ack
Packet received: 2f6c6962
Sending packet: $m10000158,4#5c...Ack
Packet received: 33322f6c
Sending packet: $m1000015c,4#87...Ack
Packet received: 642e736f
Sending packet: $m10000160,4#55...Ack
Packet received: 2e310000
Sending packet: $m2abc2a40,4#1c...Ack
Packet received: 00000001
Sending packet: $m2abc2a44,4#20...Ack
Packet received: 2abc2a58
Sending packet: $m2abc2a48,4#24...Ack
Packet received: 2aab5398
Sending packet: $qTStatus#49...Ack
Packet received:
Sending packet: $m10000208,4#58...Ack
Packet received: 131e1350
Sending packet: $m131e1350,4#90...Ack
Packet received: 2abc2a40
Sending packet: $m2abc2a44,4#20...Ack
Packet received: 2abc2a58
Sending packet: $m2abc2a58,14#56...Ack
Packet received: 000000002aabf180100001842aac233800000000
Sending packet: $m2aac2338,14#25...Ack
Packet received: 2abc30002aac23202abc31542aac26882abc2a58
Sending packet: $m2aac2320,4#eb...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2324,4#ef...Ack
Packet received: 33322f6c
Sending packet: $m2aac2328,4#f3...Ack
Packet received: 69627074
Sending packet: $m2aac232c,4#1e...Ack
Packet received: 68726561
Sending packet: $m2aac2330,4#ec...Ack
Packet received: 642e736f
Sending packet: $m2aac2334,4#f0...Ack
Packet received: 2e300000
Sending packet: $m2aac2688,14#2d...Ack
Packet received: 2acd90002aac26702acd90b42aac29d02aac2338
Sending packet: $m2aac2670,4#f3...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2674,4#f7...Ack
Packet received: 33322f6c
Sending packet: $m2aac2678,4#fb...Ack
Packet received: 69626e6c
Sending packet: $m2aac267c,4#26...Ack
Packet received: 2e736f2e
Sending packet: $m2aac2680,4#f4...Ack
Packet received: 31000000
Sending packet: $m2aac29d0,14#54...Ack
Packet received: 2ae1f0002aac29b82ae1f1342aac2d202aac2688
Sending packet: $m2aac29b8,4#29...Ack
Packet received: 2f6c6962
Sending packet: $m2aac29bc,4#54...Ack
Packet received: 33322f6c
Sending packet: $m2aac29c0,4#22...Ack
Packet received: 69626372
Sending packet: $m2aac29c4,4#26...Ack
Packet received: 7970742e
Sending packet: $m2aac29c8,4#2a...Ack
Packet received: 736f2e31
Sending packet: $m2aac29cc,4#55...Ack
Packet received: 00000000
Sending packet: $m2aac2d20,14#4d...Ack
Packet received: 2af4d0002aac2d082af4d1542aac30682aac29d0
Sending packet: $m2aac2d08,4#22...Ack
Packet received: 2f6c6962
Sending packet: $m2aac2d0c,4#4d...Ack
Packet received: 33322f6c
Sending packet: $m2aac2d10,4#1b...Ack
Packet received: 69627274
Sending packet: $m2aac2d14,4#1f...Ack
Packet received: 2e736f2e
Sending packet: $m2aac2d18,4#23...Ack
Packet received: 31000000
Sending packet: $m2aac3068,14#26...Ack
Packet received: 2b0550002aac30502b0551342aac33c02aac2d20
Sending packet: $m2aac3050,4#ec...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3054,4#f0...Ack
Packet received: 33322f6c
Sending packet: $m2aac3058,4#f4...Ack
Packet received: 69627574
Sending packet: $m2aac305c,4#1f...Ack
Packet received: 696c2e73
Sending packet: $m2aac3060,4#ed...Ack
Packet received: 6f2e3100
Sending packet: $m2aac33c0,14#4e...Ack
Packet received: 2b1580002aac33a02b1580f42aac37182aac3068
Sending packet: $m2aac33a0,4#1b...Ack
Packet received: 2f757372
Sending packet: $m2aac33a4,4#1f...Ack
Packet received: 2f6c6962
Sending packet: $m2aac33a8,4#23...Ack
Packet received: 33322f6c
Sending packet: $m2aac33ac,4#4e...Ack
Packet received: 69627374
Sending packet: $m2aac33b0,4#1c...Ack
Packet received: 64632b2b
Sending packet: $m2aac33b4,4#20...Ack
Packet received: 2e736f2e
Sending packet: $m2aac33b8,4#24...Ack
Packet received: 36000000
Sending packet: $m2aac3718,14#28...Ack
Packet received: 2b34c0002aac37002b34c1342aac3a682aac33c0
Sending packet: $m2aac3700,4#ee...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3704,4#f2...Ack
Packet received: 33322f6c
Sending packet: $m2aac3708,4#f6...Ack
Packet received: 69626d2e
Sending packet: $m2aac370c,4#21...Ack
Packet received: 736f2e36
Sending packet: $m2aac3710,4#ef...Ack
Packet received: 00000000
Sending packet: $m2aac3a68,14#57...Ack
Packet received: 2b5250002aac3a482b5250d42aac3dc02aac3718
Sending packet: $m2aac3a48,4#24...Ack
Packet received: 2f757372
Sending packet: $m2aac3a4c,4#4f...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3a50,4#1d...Ack
Packet received: 33322f6c
Sending packet: $m2aac3a54,4#21...Ack
Packet received: 69626763
Sending packet: $m2aac3a58,4#25...Ack
Packet received: 635f732e
Sending packet: $m2aac3a5c,4#50...Ack
Packet received: 736f2e31
Sending packet: $m2aac3a60,4#1e...Ack
Packet received: 00000000
Sending packet: $m2aac3dc0,14#7f...Ack
Packet received: 2b63a0002aac3da82b63a1742abc25782aac3a68
Sending packet: $m2aac3da8,4#54...Ack
Packet received: 2f6c6962
Sending packet: $m2aac3dac,4#7f...Ack
Packet received: 33322f6c
Sending packet: $m2aac3db0,4#4d...Ack
Packet received: 6962632e
Sending packet: $m2aac3db4,4#51...Ack
Packet received: 736f2e36
Sending packet: $m2aac3db8,4#55...Ack
Packet received: 00000000
Sending packet: $m2abc2578,14#2c...Ack
Packet received: 2aaa8000100001542aaa80f4000000002aac3dc0
Sending packet: $m10000154,4#58...Ack
Packet received: 2f6c6962
Sending packet: $m10000158,4#5c...Ack
Packet received: 33322f6c
Sending packet: $m1000015c,4#87...Ack
Packet received: 642e736f
Sending packet: $m10000160,4#55...Ack
Packet received: 2e310000
Sending packet: $m2abc2a40,4#1c...Ack
Packet received: 00000001
Sending packet: $m2b6d75e4,4#00...Ack
Packet received: 23bdffa0
Sending packet: $m2b6d75e8,4#04...Ack
Packet received: ffbc0058
Sending packet: $m2b6d75ec,4#2f...Ack
Packet received: 3c1c001b
Sending packet: $m2b6d75f0,4#fd...Ack
Packet received: 279cf39c
Sending packet: $m2b6d75f4,4#01...Ack
Packet received: 0399e021
Sending packet: $m2b6d75f8,4#05...Ack
Packet received: 0340182d
Sending packet: $m2b6d75fc,4#30...Ack
Packet received: 8c638ba0
Sending packet: $m2b6d7600,4#c8...Ack
Packet received: 14030009
Sending packet: $m2b6d7604,4#cc...Ack
Packet received: 00000000
Sending packet: $m2b6d7608,4#d0...Ack
Packet received: 24021792
Sending packet: $m2b6d760c,4#fb...Ack
Packet received: 0000000c
Sending packet: $m2b6d7610,4#c9...Ack
Packet received: 14e0ffe3
Sending packet: $m2b6d7614,4#cd...Ack
Packet received: 00000000
Sending packet: $m2b6d7618,4#d1...Ack
Packet received: dfbc0058
Sending packet: $m2b6d761c,4#fc...Ack
Packet received: 03e00008
Sending packet: $qTStatus#49...Ack
Packet received:
Sending packet: $qTStatus#49...Ack
Packet received:
Sending packet: $qTStatus#49...Ack
Packet received:
Sending packet: $qTStatus#49...Ack
Packet received:
(gdb) bt
Sending packet: $m2b6d7654,4#d1...Ack
Packet received: ffa20040
Sending packet: $m2b6d7650,4#cd...Ack
Packet received: 0000000c
Sending packet: $m7fbc3a00,40#53...Ack
Packet received: 0000000011b08ea8ffffffffffffffff0000000a00000001000000007fbc3a50000000007fbc3a50000000002b6d72f4ffffffffffffffff00000000000
00000
#0 0x2b6d7654 in nanosleep () from D:/sysroot/octeon17/lib32/libc.so.6
Sending packet: $m2b6d72f4,4#fe...Ack
Packet received: 1440002c
Sending packet: $m2b6d72f0,4#fa...Ack
Packet received: 03a0282d
Sending packet: $m7fbc3c00,40#55...Ack
Packet received: 00000000000000000000000120272ae80000000120272ae80000000000000000000000000000000200000000131e93500000000010756d6000000000107
56d4c
#1 0x2b6d72f4 in __sleep (Sending packet: $g#67...Ack
Packet received: 0000000000000000ffffffff8057000000000000000002040000000000000000000000007fbc3a50000000007fbc3a50000000002aac4c9000000000000
000010000000000000003000000007fbc39c00000000000000003000000000000000300000000000000000000000000008c00a800000412afc000a800000412afc0000000000
000000001000000007fbc3a5800000000000000000000000000020000000000007fbc3ad8000000007fffffff000000007fffffff00000000000000000000000000000000000
000002b71eb9000000000000000000000000000000000000000002b886980000000007fbc39f0000000ffffe27fb8000000002b6d7640000000000000000000000000002dc6c
00000000000000000000000002aac4cec0000000000800020000000002b6d7654fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000
seconds=<error reading variable: Remote 'g' packet reply is too long: 0000000000000000ffffffff805700000000000000000204000000000000000000
0000007fbc3a50000000007fbc3a50000000002aac4c9000000000000000010000000000000003000000007fbc39c00000000000000003000000000000000300000000000000
000000000000008c00a800000412afc000a800000412afc0000000000000000001000000007fbc3a5800000000000000000000000000020000000000007fbc3ad8000000007f
ffffff000000007fffffff00000000000000000000000000000000000000002b71eb9000000000000000000000000000000000000000002b886980000000007fbc39f0000000
ffffe27fb8000000002b6d7640000000000000000000000000002dc6c00000000000000000000000002aac4cec0000000000800020000000002b6d7654ffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000>)
at ../sysdeps/unix/sysv/linux/sleep.c:138
Sending packet: $m10756d60,4#9a...Ack
Packet received: 1000fffd
Sending packet: $m10756d5c,4#cc...Ack
Packet received: 24040001
Sending packet: $m7fbc3c40,40#59...Ack
Packet received: 000000002abc1f080000000000000000000000002b886980000000002b64ff78000000002b64ff48000000007fbc3c60000000002abc1f0800000000000
00000
#2 0x10756d60 in main (argc=<optimized out>, Sending packet: $m7fbc3bc0,40#87...Ack
Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007fbc3e49000000007fb
c3d64
Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
argv=0x7fbc3d64)
at /home/orgads/file.cpp:153
(gdb) info threads
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m195
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m212
[New Thread 530]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m20f
[New Thread 527]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m20d
[New Thread 525]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m20c
[New Thread 524]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m20b
[New Thread 523]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m209
[New Thread 521]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m208
[New Thread 520]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m207
[New Thread 519]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m206
[New Thread 518]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m204
[New Thread 516]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m203
[New Thread 515]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m202
[New Thread 514]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m201
[New Thread 513]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m200
[New Thread 512]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1ff
[New Thread 511]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1fe
[New Thread 510]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1fc
[New Thread 508]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1fb
[New Thread 507]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1fa
[New Thread 506]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f9
[New Thread 505]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f8
[New Thread 504]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f7
[New Thread 503]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f6
[New Thread 502]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f3
[New Thread 499]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f2
[New Thread 498]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f1
[New Thread 497]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1f0
[New Thread 496]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1ef
[New Thread 495]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1e8
[New Thread 488]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1e6
[New Thread 486]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1e5
[New Thread 485]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1e4
[New Thread 484]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1e3
[New Thread 483]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1e2
[New Thread 482]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1df
[New Thread 479]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1bb
[New Thread 443]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1b9
[New Thread 441]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m1b7
[New Thread 439]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m19a
[New Thread 410]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m199
[New Thread 409]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: m198
[New Thread 408]
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
Id Target Id Frame
42 Sending packet: $qThreadExtraInfo,198#27...Ack
Packet received:
Sending packet: $qP0000001f0000000000000198#8a...Ack
Packet received:
Thread 408 Sending packet: $Hg198#51...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000010008ce1000000000000020200000000000000000000000000000000000000002ab925b0000000000000000800000000000
0000100000000000000000000000000000000000000000000000400000028000000000000000000000000000000002ab925b40000000000000008a8000004124b40000000000
0132ba258ffffffffffffffff000000000000000000000000132ba278000000002ab92c300000000000000000000000000000000000000000241952fa0000000000000004000
000002b71eb9000000000000000000000000000000000000000002b886980000000002ab925500000000000000001000000002b711e0c0000000000000000000000000000000
00000000000000000000000002d744e140000000000800020000000002b711e2cfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000
Sending packet: $Hg195#4e...Ack
Packet received: OK
Sending packet: $m2b6d7654,4#d1...Ack
Packet received: ffa20040
Sending packet: $m2b6d7650,4#cd...Ack
Packet received: 0000000c
Sending packet: $m7fbc3a00,40#53...Ack
Packet received: 0000000011b08ea8ffffffffffffffff0000000a00000001000000007fbc3a50000000007fbc3a50000000002b6d72f4ffffffffffffffff00000000000
00000
Remote 'g' packet reply is too long: 00000000000000000000000010008ce1000000000000020200000000000000000000000000000000000000002ab925b00000000
000000008000000000000000100000000000000000000000000000000000000000000000400000028000000000000000000000000000000002ab925b40000000000000008a80
00004124b400000000000132ba258ffffffffffffffff000000000000000000000000132ba278000000002ab92c300000000000000000000000000000000000000000241952f
a0000000000000004000000002b71eb9000000000000000000000000000000000000000002b886980000000002ab925500000000000000001000000002b711e0c00000000000
0000000000000000000000000000000000000000000002d744e140000000000800020000000002b711e2cfffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb) detach
Sending packet: $qTStatus#49...Ack
Packet received:
Detaching from program: D:\target.elf, Remote target
Sending packet: $D#44...Ack
Packet received: OK
Ending remote debugging.
(gdb) quit
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 5:43 ` Orgad Shaneh
@ 2016-04-13 19:11 ` Luis Machado
2016-04-13 20:07 ` Orgad Shaneh
0 siblings, 1 reply; 16+ messages in thread
From: Luis Machado @ 2016-04-13 19:11 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: gdb-patches
On 04/13/2016 12:43 AM, Orgad Shaneh wrote:
>>> I got this message when I tried to remotely debug a
>>> mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
>>>
>>> GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
>>> and the debugger stops functioning.
>>>
>>
>> I suppose GDB 7.5 is slightly incompatible with older gdbserver versions.
>>
>> What kind of target description does gdbserver return in this case (set
>> debug remote 1)?
>
> Full log attached. Thanks for your help.
>
> - Orgad
>
Strange. If this is gdbserver 6.8, it should've replied to the
qSupported packet? That one was added in 6.6.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 19:11 ` Luis Machado
@ 2016-04-13 20:07 ` Orgad Shaneh
2016-04-13 20:27 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-13 20:07 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb-patches
On Wed, Apr 13, 2016 at 10:11 PM, Luis Machado
<lgustavo@codesourcery.com> wrote:
>
> On 04/13/2016 12:43 AM, Orgad Shaneh wrote:
>>>>
>>>> I got this message when I tried to remotely debug a
>>>> mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
>>>>
>>>> GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
>>>> and the debugger stops functioning.
>>>>
>>>
>>> I suppose GDB 7.5 is slightly incompatible with older gdbserver versions.
>>>
>>> What kind of target description does gdbserver return in this case (set
>>> debug remote 1)?
>>
>>
>> Full log attached. Thanks for your help.
>>
>> - Orgad
>>
>
> Strange. If this is gdbserver 6.8, it should've replied to the qSupported packet? That one was added in 6.6.
Hi,
Sorry, my fault. The gdbserver is GNU gdb 6.5 Cavium Networks Version:
1_7_0, build 45
gdbserver 6.8 is in Cavium SDK2. I don't know if it works with recent GDB.
- Orgad
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 20:07 ` Orgad Shaneh
@ 2016-04-13 20:27 ` Pedro Alves
2016-04-13 20:52 ` Orgad Shaneh
0 siblings, 1 reply; 16+ messages in thread
From: Pedro Alves @ 2016-04-13 20:27 UTC (permalink / raw)
To: Orgad Shaneh, Luis Machado; +Cc: gdb-patches
On 04/13/2016 09:07 PM, Orgad Shaneh wrote:
> On Wed, Apr 13, 2016 at 10:11 PM, Luis Machado
> <lgustavo@codesourcery.com> wrote:
>>
>> On 04/13/2016 12:43 AM, Orgad Shaneh wrote:
>>>>>
>>>>> I got this message when I tried to remotely debug a
>>>>> mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
>>>>>
>>>>> GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
>>>>> and the debugger stops functioning.
>>>>>
>>>>
>>>> I suppose GDB 7.5 is slightly incompatible with older gdbserver versions.
>>>>
>>>> What kind of target description does gdbserver return in this case (set
>>>> debug remote 1)?
>>>
>>>
>>> Full log attached. Thanks for your help.
>>>
>>> - Orgad
>>>
>>
>> Strange. If this is gdbserver 6.8, it should've replied to the qSupported packet? That one was added in 6.6.
>
>
> Hi,
>
> Sorry, my fault. The gdbserver is GNU gdb 6.5 Cavium Networks Version:
> 1_7_0, build 45
>
> gdbserver 6.8 is in Cavium SDK2. I don't know if it works with recent GDB.
>
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?
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 20:27 ` Pedro Alves
@ 2016-04-13 20:52 ` Orgad Shaneh
2016-04-13 21:57 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-13 20:52 UTC (permalink / raw)
To: Pedro Alves; +Cc: Luis Machado, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]
On Wed, Apr 13, 2016 at 11:27 PM, Pedro Alves <palves@redhat.com> wrote:
> On 04/13/2016 09:07 PM, Orgad Shaneh wrote:
>> On Wed, Apr 13, 2016 at 10:11 PM, Luis Machado
>> <lgustavo@codesourcery.com> wrote:
>>>
>>> On 04/13/2016 12:43 AM, Orgad Shaneh wrote:
>>>>>>
>>>>>> I got this message when I tried to remotely debug a
>>>>>> mips64-octeon-linux gdbserver 6.8 with GDB >= 7.5.
>>>>>>
>>>>>> GDB <= 7.4.1 works well, but with 7.5 and up I receive this message
>>>>>> and the debugger stops functioning.
>>>>>>
>>>>>
>>>>> I suppose GDB 7.5 is slightly incompatible with older gdbserver versions.
>>>>>
>>>>> What kind of target description does gdbserver return in this case (set
>>>>> debug remote 1)?
>>>>
>>>>
>>>> Full log attached. Thanks for your help.
>>>>
>>>> - Orgad
>>>>
>>>
>>> Strange. If this is gdbserver 6.8, it should've replied to the qSupported packet? That one was added in 6.6.
>>
>>
>> Hi,
>>
>> Sorry, my fault. The gdbserver is GNU gdb 6.5 Cavium Networks Version:
>> 1_7_0, build 45
>>
>> gdbserver 6.8 is in Cavium SDK2. I don't know if it works with recent GDB.
>>
>
> 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.
[-- Attachment #2: gdb-local-6.5.txt --]
[-- Type: text/plain, Size: 8928 bytes --]
(gdb) main print registers
Name Nr Rel Offset Size Type
'' 0 0 0 8 int64_t
'' 1 1 8 8 int64_t
'' 2 2 16 8 int64_t
'' 3 3 24 8 int64_t
'' 4 4 32 8 int64_t
'' 5 5 40 8 int64_t
'' 6 6 48 8 int64_t
'' 7 7 56 8 int64_t
'' 8 8 64 8 int64_t
'' 9 9 72 8 int64_t
'' 10 10 80 8 int64_t
'' 11 11 88 8 int64_t
'' 12 12 96 8 int64_t
'' 13 13 104 8 int64_t
'' 14 14 112 8 int64_t
'' 15 15 120 8 int64_t
'' 16 16 128 8 int64_t
'' 17 17 136 8 int64_t
'' 18 18 144 8 int64_t
'' 19 19 152 8 int64_t
'' 20 20 160 8 int64_t
'' 21 21 168 8 int64_t
'' 22 22 176 8 int64_t
'' 23 23 184 8 int64_t
'' 24 24 192 8 int64_t
'' 25 25 200 8 int64_t
'' 26 26 208 8 int64_t
'' 27 27 216 8 int64_t
'' 28 28 224 8 int64_t
'' 29 29 232 8 int64_t
'' 30 30 240 8 int64_t
'' 31 31 248 8 int64_t
'' 32 32 256 8 int64_t
'' 33 33 264 8 int64_t
'' 34 34 272 8 int64_t
'' 35 35 280 8 int64_t
'' 36 36 288 8 int64_t
'' 37 37 296 8 int64_t
'' 38 38 304 8 _ieee_double_big
'' 39 39 312 8 _ieee_double_big
'' 40 40 320 8 _ieee_double_big
'' 41 41 328 8 _ieee_double_big
'' 42 42 336 8 _ieee_double_big
'' 43 43 344 8 _ieee_double_big
'' 44 44 352 8 _ieee_double_big
'' 45 45 360 8 _ieee_double_big
'' 46 46 368 8 _ieee_double_big
'' 47 47 376 8 _ieee_double_big
'' 48 48 384 8 _ieee_double_big
'' 49 49 392 8 _ieee_double_big
'' 50 50 400 8 _ieee_double_big
'' 51 51 408 8 _ieee_double_big
'' 52 52 416 8 _ieee_double_big
'' 53 53 424 8 _ieee_double_big
'' 54 54 432 8 _ieee_double_big
'' 55 55 440 8 _ieee_double_big
'' 56 56 448 8 _ieee_double_big
'' 57 57 456 8 _ieee_double_big
'' 58 58 464 8 _ieee_double_big
'' 59 59 472 8 _ieee_double_big
'' 60 60 480 8 _ieee_double_big
'' 61 61 488 8 _ieee_double_big
'' 62 62 496 8 _ieee_double_big
'' 63 63 504 8 _ieee_double_big
'' 64 64 512 8 _ieee_double_big
'' 65 65 520 8 _ieee_double_big
'' 66 66 528 8 _ieee_double_big
'' 67 67 536 8 _ieee_double_big
'' 68 68 544 8 _ieee_double_big
'' 69 69 552 8 _ieee_double_big
'' 70 70 560 8 int64_t
'' 71 71 568 8 int64_t
'' 72 72 576 8 int64_t
'' 73 73 584 8 int64_t
'' 74 74 592 8 int64_t
'' 75 75 600 8 int64_t
'' 76 76 608 8 int64_t
'' 77 77 616 8 int64_t
'' 78 78 624 8 int64_t
'' 79 79 632 8 int64_t
'' 80 80 640 8 int64_t
'' 81 81 648 8 int64_t
'' 82 82 656 8 int64_t
'' 83 83 664 8 int64_t
'' 84 84 672 8 int64_t
'' 85 85 680 8 int64_t
'' 86 86 688 8 int64_t
'' 87 87 696 8 int64_t
'' 88 88 704 8 int64_t
'' 89 89 712 8 int64_t
zero 90 0 720 8 int64_t
at 91 1 728 8 int64_t
v0 92 2 736 8 int64_t
v1 93 3 744 8 int64_t
a0 94 4 752 8 int64_t
a1 95 5 760 8 int64_t
a2 96 6 768 8 int64_t
a3 97 7 776 8 int64_t
a4 98 8 784 8 int64_t
a5 99 9 792 8 int64_t
a6 100 10 800 8 int64_t
a7 101 11 808 8 int64_t
t0 102 12 816 8 int64_t
t1 103 13 824 8 int64_t
t2 104 14 832 8 int64_t
t3 105 15 840 8 int64_t
s0 106 16 848 8 int64_t
s1 107 17 856 8 int64_t
s2 108 18 864 8 int64_t
s3 109 19 872 8 int64_t
s4 110 20 880 8 int64_t
s5 111 21 888 8 int64_t
s6 112 22 896 8 int64_t
s7 113 23 904 8 int64_t
t8 114 24 912 8 int64_t
t9 115 25 920 8 int64_t
k0 116 26 928 8 int64_t
k1 117 27 936 8 int64_t
gp 118 28 944 8 int64_t
sp 119 29 952 8 int64_t
s8 120 30 960 8 int64_t
ra 121 31 968 8 int64_t
sr 122 32 976 8 int64_t
lo 123 33 984 8 int64_t
hi 124 34 992 8 int64_t
bad 125 35 1000 8 int64_t
cause 126 36 1008 8 int64_t
pc 127 37 1016 8 int64_t
'' 128 38 1024 8 _ieee_double_big
'' 129 39 1032 8 _ieee_double_big
'' 130 40 1040 8 _ieee_double_big
'' 131 41 1048 8 _ieee_double_big
'' 132 42 1056 8 _ieee_double_big
'' 133 43 1064 8 _ieee_double_big
'' 134 44 1072 8 _ieee_double_big
'' 135 45 1080 8 _ieee_double_big
'' 136 46 1088 8 _ieee_double_big
'' 137 47 1096 8 _ieee_double_big
'' 138 48 1104 8 _ieee_double_big
'' 139 49 1112 8 _ieee_double_big
'' 140 50 1120 8 _ieee_double_big
'' 141 51 1128 8 _ieee_double_big
'' 142 52 1136 8 _ieee_double_big
'' 143 53 1144 8 _ieee_double_big
'' 144 54 1152 8 _ieee_double_big
'' 145 55 1160 8 _ieee_double_big
'' 146 56 1168 8 _ieee_double_big
'' 147 57 1176 8 _ieee_double_big
'' 148 58 1184 8 _ieee_double_big
'' 149 59 1192 8 _ieee_double_big
'' 150 60 1200 8 _ieee_double_big
'' 151 61 1208 8 _ieee_double_big
'' 152 62 1216 8 _ieee_double_big
'' 153 63 1224 8 _ieee_double_big
'' 154 64 1232 8 _ieee_double_big
'' 155 65 1240 8 _ieee_double_big
'' 156 66 1248 8 _ieee_double_big
'' 157 67 1256 8 _ieee_double_big
'' 158 68 1264 8 _ieee_double_big
'' 159 69 1272 8 _ieee_double_big
'' 160 70 1280 4 int32_t
'' 161 71 1284 4 int32_t
'' 162 72 1288 4 int32_t
'' 163 73 1292 4 int32_t
'' 164 74 1296 4 int32_t
'' 165 75 1300 4 int32_t
'' 166 76 1304 4 int32_t
'' 167 77 1308 4 int32_t
'' 168 78 1312 4 int32_t
'' 169 79 1316 4 int32_t
'' 170 80 1320 4 int32_t
'' 171 81 1324 4 int32_t
'' 172 82 1328 4 int32_t
'' 173 83 1332 4 int32_t
'' 174 84 1336 4 int32_t
'' 175 85 1340 4 int32_t
'' 176 86 1344 4 int32_t
'' 177 87 1348 4 int32_t
'' 178 88 1352 4 int32_t
'' 179 89 1356 4 int32_t
[-- Attachment #3: gdb-remote-7.4.txt --]
[-- Type: text/plain, Size: 10875 bytes --]
(gdb) main print remote-registers
Name Nr Rel Offset Size Type Rmt Nr g/G Offset
'' 0 0 0 8 int64_t 0 0
'' 1 1 8 8 int64_t 1 8
'' 2 2 16 8 int64_t 2 16
'' 3 3 24 8 int64_t 3 24
'' 4 4 32 8 int64_t 4 32
'' 5 5 40 8 int64_t 5 40
'' 6 6 48 8 int64_t 6 48
'' 7 7 56 8 int64_t 7 56
'' 8 8 64 8 int64_t 8 64
'' 9 9 72 8 int64_t 9 72
'' 10 10 80 8 int64_t 10 80
'' 11 11 88 8 int64_t 11 88
'' 12 12 96 8 int64_t 12 96
'' 13 13 104 8 int64_t 13 104
'' 14 14 112 8 int64_t 14 112
'' 15 15 120 8 int64_t 15 120
'' 16 16 128 8 int64_t 16 128
'' 17 17 136 8 int64_t 17 136
'' 18 18 144 8 int64_t 18 144
'' 19 19 152 8 int64_t 19 152
'' 20 20 160 8 int64_t 20 160
'' 21 21 168 8 int64_t 21 168
'' 22 22 176 8 int64_t 22 176
'' 23 23 184 8 int64_t 23 184
'' 24 24 192 8 int64_t 24 192
'' 25 25 200 8 int64_t 25 200
'' 26 26 208 8 int64_t 26 208
'' 27 27 216 8 int64_t 27 216
'' 28 28 224 8 int64_t 28 224
'' 29 29 232 8 int64_t 29 232
'' 30 30 240 8 int64_t 30 240
'' 31 31 248 8 int64_t 31 248
'' 32 32 256 8 int64_t 32 256
'' 33 33 264 8 int64_t 33 264
'' 34 34 272 8 int64_t 34 272
'' 35 35 280 8 int64_t 35 280
'' 36 36 288 8 int64_t 36 288
'' 37 37 296 8 int64_t 37 296
'' 38 38 304 8 double 38 304
'' 39 39 312 8 double 39 312
'' 40 40 320 8 double 40 320
'' 41 41 328 8 double 41 328
'' 42 42 336 8 double 42 336
'' 43 43 344 8 double 43 344
'' 44 44 352 8 double 44 352
'' 45 45 360 8 double 45 360
'' 46 46 368 8 double 46 368
'' 47 47 376 8 double 47 376
'' 48 48 384 8 double 48 384
'' 49 49 392 8 double 49 392
'' 50 50 400 8 double 50 400
'' 51 51 408 8 double 51 408
'' 52 52 416 8 double 52 416
'' 53 53 424 8 double 53 424
'' 54 54 432 8 double 54 432
'' 55 55 440 8 double 55 440
'' 56 56 448 8 double 56 448
'' 57 57 456 8 double 57 456
'' 58 58 464 8 double 58 464
'' 59 59 472 8 double 59 472
'' 60 60 480 8 double 60 480
'' 61 61 488 8 double 61 488
'' 62 62 496 8 double 62 496
'' 63 63 504 8 double 63 504
'' 64 64 512 8 double 64 512
'' 65 65 520 8 double 65 520
'' 66 66 528 8 double 66 528
'' 67 67 536 8 double 67 536
'' 68 68 544 8 double 68 544
'' 69 69 552 8 double 69 552
'' 70 70 560 8 int64_t 70 560
'' 71 71 568 8 int64_t 71 568
'' 72 72 576 8 int64_t 72 576
'' 73 73 584 8 int64_t 73 584
'' 74 74 592 8 int64_t 74 592
'' 75 75 600 8 int64_t 75 600
'' 76 76 608 8 int64_t 76 608
'' 77 77 616 8 int64_t 77 616
'' 78 78 624 8 int64_t 78 624
'' 79 79 632 8 int64_t 79 632
'' 80 80 640 8 int64_t 80 640
'' 81 81 648 8 int64_t 81 648
'' 82 82 656 8 int64_t 82 656
'' 83 83 664 8 int64_t 83 664
'' 84 84 672 8 int64_t 84 672
'' 85 85 680 8 int64_t 85 680
'' 86 86 688 8 int64_t 86 688
'' 87 87 696 8 int64_t 87 696
'' 88 88 704 8 int64_t 88 704
'' 89 89 712 8 int64_t 89 712
zero 90 0 720 8 int64_t
at 91 1 728 8 int64_t
v0 92 2 736 8 int64_t
v1 93 3 744 8 int64_t
a0 94 4 752 8 int64_t
a1 95 5 760 8 int64_t
a2 96 6 768 8 int64_t
a3 97 7 776 8 int64_t
a4 98 8 784 8 int64_t
a5 99 9 792 8 int64_t
a6 100 10 800 8 int64_t
a7 101 11 808 8 int64_t
t0 102 12 816 8 int64_t
t1 103 13 824 8 int64_t
t2 104 14 832 8 int64_t
t3 105 15 840 8 int64_t
s0 106 16 848 8 int64_t
s1 107 17 856 8 int64_t
s2 108 18 864 8 int64_t
s3 109 19 872 8 int64_t
s4 110 20 880 8 int64_t
s5 111 21 888 8 int64_t
s6 112 22 896 8 int64_t
s7 113 23 904 8 int64_t
t8 114 24 912 8 int64_t
t9 115 25 920 8 int64_t
k0 116 26 928 8 int64_t
k1 117 27 936 8 int64_t
gp 118 28 944 8 int64_t
sp 119 29 952 8 int64_t
s8 120 30 960 8 int64_t
ra 121 31 968 8 int64_t
sr 122 32 976 8 int64_t
lo 123 33 984 8 int64_t
hi 124 34 992 8 int64_t
bad 125 35 1000 8 int64_t
cause 126 36 1008 8 int64_t
pc 127 37 1016 8 int64_t
f0 128 38 1024 8 double
f1 129 39 1032 8 double
f2 130 40 1040 8 double
f3 131 41 1048 8 double
f4 132 42 1056 8 double
f5 133 43 1064 8 double
f6 134 44 1072 8 double
f7 135 45 1080 8 double
f8 136 46 1088 8 double
f9 137 47 1096 8 double
f10 138 48 1104 8 double
f11 139 49 1112 8 double
f12 140 50 1120 8 double
f13 141 51 1128 8 double
f14 142 52 1136 8 double
f15 143 53 1144 8 double
f16 144 54 1152 8 double
f17 145 55 1160 8 double
f18 146 56 1168 8 double
f19 147 57 1176 8 double
f20 148 58 1184 8 double
f21 149 59 1192 8 double
f22 150 60 1200 8 double
f23 151 61 1208 8 double
f24 152 62 1216 8 double
f25 153 63 1224 8 double
f26 154 64 1232 8 double
f27 155 65 1240 8 double
f28 156 66 1248 8 double
f29 157 67 1256 8 double
f30 158 68 1264 8 double
f31 159 69 1272 8 double
fsr 160 70 1280 4 int32_t
fir 161 71 1284 4 int32_t
'' 162 72 1288 4 int32_t
'' 163 73 1292 4 int32_t
'' 164 74 1296 4 int32_t
'' 165 75 1300 4 int32_t
'' 166 76 1304 4 int32_t
'' 167 77 1308 4 int32_t
'' 168 78 1312 4 int32_t
'' 169 79 1316 4 int32_t
'' 170 80 1320 4 int32_t
'' 171 81 1324 4 int32_t
'' 172 82 1328 4 int32_t
'' 173 83 1332 4 int32_t
'' 174 84 1336 4 int32_t
'' 175 85 1340 4 int32_t
'' 176 86 1344 4 int32_t
'' 177 87 1348 4 int32_t
'' 178 88 1352 4 int32_t
'' 179 89 1356 4 int32_t
[-- Attachment #4: gdb-remote-7.6.txt --]
[-- Type: text/plain, Size: 9555 bytes --]
(gdb) main print remote-registers
Name Nr Rel Offset Size Type Rmt Nr g/G Offset
'' 0 0 0 8 int64_t 0 0
'' 1 1 8 8 int64_t 1 8
'' 2 2 16 8 int64_t 2 16
'' 3 3 24 8 int64_t 3 24
'' 4 4 32 8 int64_t 4 32
'' 5 5 40 8 int64_t 5 40
'' 6 6 48 8 int64_t 6 48
'' 7 7 56 8 int64_t 7 56
'' 8 8 64 8 int64_t 8 64
'' 9 9 72 8 int64_t 9 72
'' 10 10 80 8 int64_t 10 80
'' 11 11 88 8 int64_t 11 88
'' 12 12 96 8 int64_t 12 96
'' 13 13 104 8 int64_t 13 104
'' 14 14 112 8 int64_t 14 112
'' 15 15 120 8 int64_t 15 120
'' 16 16 128 8 int64_t 16 128
'' 17 17 136 8 int64_t 17 136
'' 18 18 144 8 int64_t 18 144
'' 19 19 152 8 int64_t 19 152
'' 20 20 160 8 int64_t 20 160
'' 21 21 168 8 int64_t 21 168
'' 22 22 176 8 int64_t 22 176
'' 23 23 184 8 int64_t 23 184
'' 24 24 192 8 int64_t 24 192
'' 25 25 200 8 int64_t 25 200
'' 26 26 208 8 int64_t 26 208
'' 27 27 216 8 int64_t 27 216
'' 28 28 224 8 int64_t 28 224
'' 29 29 232 8 int64_t 29 232
'' 30 30 240 8 int64_t 30 240
'' 31 31 248 8 int64_t 31 248
'' 32 32 256 8 int64_t 32 256
'' 33 33 264 8 int64_t 33 264
'' 34 34 272 8 int64_t 34 272
'' 35 35 280 8 int64_t 35 280
'' 36 36 288 8 int64_t 36 288
'' 37 37 296 8 int64_t 37 296
'' 38 38 304 8 double 38 304
'' 39 39 312 8 double 39 312
'' 40 40 320 8 double 40 320
'' 41 41 328 8 double 41 328
'' 42 42 336 8 double 42 336
'' 43 43 344 8 double 43 344
'' 44 44 352 8 double 44 352
'' 45 45 360 8 double 45 360
'' 46 46 368 8 double 46 368
'' 47 47 376 8 double 47 376
'' 48 48 384 8 double 48 384
'' 49 49 392 8 double 49 392
'' 50 50 400 8 double 50 400
'' 51 51 408 8 double 51 408
'' 52 52 416 8 double 52 416
'' 53 53 424 8 double 53 424
'' 54 54 432 8 double 54 432
'' 55 55 440 8 double 55 440
'' 56 56 448 8 double 56 448
'' 57 57 456 8 double 57 456
'' 58 58 464 8 double 58 464
'' 59 59 472 8 double 59 472
'' 60 60 480 8 double 60 480
'' 61 61 488 8 double 61 488
'' 62 62 496 8 double 62 496
'' 63 63 504 8 double 63 504
'' 64 64 512 8 double 64 512
'' 65 65 520 8 double 65 520
'' 66 66 528 8 double 66 528
'' 67 67 536 8 double 67 536
'' 68 68 544 8 double 68 544
'' 69 69 552 8 double 69 552
'' 70 70 560 8 int64_t 70 560
'' 71 71 568 8 int64_t 71 568
'' 72 72 576 8 int64_t 72 576
'' 73 73 584 8 int64_t 73 584
'' 74 74 592 8 int64_t 74 592
'' 75 75 600 8 int64_t 75 600
'' 76 76 608 8 int64_t 76 608
'' 77 77 616 8 int64_t 77 616
'' 78 78 624 8 int64_t 78 624
zero 79 0 632 8 int64_t
at 80 1 640 8 int64_t
v0 81 2 648 8 int64_t
v1 82 3 656 8 int64_t
a0 83 4 664 8 int64_t
a1 84 5 672 8 int64_t
a2 85 6 680 8 int64_t
a3 86 7 688 8 int64_t
a4 87 8 696 8 int64_t
a5 88 9 704 8 int64_t
a6 89 10 712 8 int64_t
a7 90 11 720 8 int64_t
t0 91 12 728 8 int64_t
t1 92 13 736 8 int64_t
t2 93 14 744 8 int64_t
t3 94 15 752 8 int64_t
s0 95 16 760 8 int64_t
s1 96 17 768 8 int64_t
s2 97 18 776 8 int64_t
s3 98 19 784 8 int64_t
s4 99 20 792 8 int64_t
s5 100 21 800 8 int64_t
s6 101 22 808 8 int64_t
s7 102 23 816 8 int64_t
t8 103 24 824 8 int64_t
t9 104 25 832 8 int64_t
k0 105 26 840 8 int64_t
k1 106 27 848 8 int64_t
gp 107 28 856 8 int64_t
sp 108 29 864 8 int64_t
s8 109 30 872 8 int64_t
ra 110 31 880 8 int64_t
sr 111 32 888 8 int64_t
lo 112 33 896 8 int64_t
hi 113 34 904 8 int64_t
bad 114 35 912 8 int64_t
cause 115 36 920 8 int64_t
pc 116 37 928 8 int64_t
f0 117 38 936 8 double
f1 118 39 944 8 double
f2 119 40 952 8 double
f3 120 41 960 8 double
f4 121 42 968 8 double
f5 122 43 976 8 double
f6 123 44 984 8 double
f7 124 45 992 8 double
f8 125 46 1000 8 double
f9 126 47 1008 8 double
f10 127 48 1016 8 double
f11 128 49 1024 8 double
f12 129 50 1032 8 double
f13 130 51 1040 8 double
f14 131 52 1048 8 double
f15 132 53 1056 8 double
f16 133 54 1064 8 double
f17 134 55 1072 8 double
f18 135 56 1080 8 double
f19 136 57 1088 8 double
f20 137 58 1096 8 double
f21 138 59 1104 8 double
f22 139 60 1112 8 double
f23 140 61 1120 8 double
f24 141 62 1128 8 double
f25 142 63 1136 8 double
f26 143 64 1144 8 double
f27 144 65 1152 8 double
f28 145 66 1160 8 double
f29 146 67 1168 8 double
f30 147 68 1176 8 double
f31 148 69 1184 8 double
fsr 149 70 1192 4 int32_t
fir 150 71 1196 4 int32_t
'' 151 72 1200 8 int64_t
'' 152 73 1208 8 int64_t
'' 153 74 1216 8 int64_t
'' 154 75 1224 8 int64_t
'' 155 76 1232 8 int64_t
'' 156 77 1240 8 int64_t
'' 157 78 1248 8 int64_t
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 20:52 ` Orgad Shaneh
@ 2016-04-13 21:57 ` Pedro Alves
2016-04-14 8:33 ` Orgad Shaneh
2016-04-14 21:21 ` Maciej W. Rozycki
0 siblings, 2 replies; 16+ messages in thread
From: Pedro Alves @ 2016-04-13 21:57 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: Luis Machado, gdb-patches
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 21:57 ` Pedro Alves
@ 2016-04-14 8:33 ` Orgad Shaneh
2016-04-14 9:07 ` Orgad Shaneh
2016-04-14 21:21 ` Maciej W. Rozycki
1 sibling, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-14 8:33 UTC (permalink / raw)
To: Pedro Alves; +Cc: Luis Machado, gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-14 8:33 ` Orgad Shaneh
@ 2016-04-14 9:07 ` Orgad Shaneh
2016-04-14 9:22 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-14 9:07 UTC (permalink / raw)
To: Pedro Alves; +Cc: Luis Machado, gdb-patches
On Thu, Apr 14, 2016 at 11:33 AM, Orgad Shaneh <orgads@gmail.com> wrote:
> On Thu, Apr 14, 2016 at 12:57 AM, Pedro Alves <palves@redhat.com> wrote:
>>> 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...
Ok, autoconf helped. FSF gdbserver 6.5 has the same issue when the gdb
client is >=7.5: "Remote 'g' packet reply is too long".
So this doesn't seem to be related to Cavium patches.
- Orgad
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-14 9:07 ` Orgad Shaneh
@ 2016-04-14 9:22 ` Pedro Alves
2016-04-14 9:39 ` Orgad Shaneh
0 siblings, 1 reply; 16+ messages in thread
From: Pedro Alves @ 2016-04-14 9:22 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: Luis Machado, gdb-patches
On 04/14/2016 10:06 AM, Orgad Shaneh wrote:
> Ok, autoconf helped. FSF gdbserver 6.5 has the same issue when the gdb
> client is >=7.5: "Remote 'g' packet reply is too long".
>
> So this doesn't seem to be related to Cavium patches.
Since you can build gdb now, you should be able to use "git bisect"
to find the culprit.
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-14 9:22 ` Pedro Alves
@ 2016-04-14 9:39 ` Orgad Shaneh
2016-04-14 9:47 ` Pedro Alves
0 siblings, 1 reply; 16+ messages in thread
From: Orgad Shaneh @ 2016-04-14 9:39 UTC (permalink / raw)
To: Pedro Alves; +Cc: Luis Machado, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On Thu, Apr 14, 2016 at 12:22 PM, Pedro Alves <palves@redhat.com> wrote:
> On 04/14/2016 10:06 AM, Orgad Shaneh wrote:
>
>> Ok, autoconf helped. FSF gdbserver 6.5 has the same issue when the gdb
>> client is >=7.5: "Remote 'g' packet reply is too long".
>>
>> So this doesn't seem to be related to Cavium patches.
>
> Since you can build gdb now, you should be able to use "git bisect"
> to find the culprit.
>
> Thanks,
> Pedro Alves
>
Good point. The first bad commit is 1faeff08.
Bisect log attached.
- Orgad
[-- Attachment #2: bisect.log --]
[-- Type: application/octet-stream, Size: 2754 bytes --]
git bisect start
# good: [66a5c7c17c5f2afb94e0eae4a7de6bb83eaeab62] NEWS: Change "since GDB 7.3.1" into "in GDB 7.4".
git bisect good 66a5c7c17c5f2afb94e0eae4a7de6bb83eaeab62
# bad: [3c2f71b3160efd230669cbb53d77178c23403aea] Update GDB version number in version.in
git bisect bad 3c2f71b3160efd230669cbb53d77178c23403aea
# bad: [3c2f71b3160efd230669cbb53d77178c23403aea] Update GDB version number in version.in
git bisect bad 3c2f71b3160efd230669cbb53d77178c23403aea
# good: [c5012cd8d53be0c5a3b0b4ae2a054b0a3dadbca2] bfd/ 2011-12-13 Tristan Gingold <gingold@adacore.com>
git bisect good c5012cd8d53be0c5a3b0b4ae2a054b0a3dadbca2
# bad: [ece0061f93a5a99e3f5b063d271267b6414cd129] 2012-04-02 Tristan Gingold <gingold@adacore.com>
git bisect bad ece0061f93a5a99e3f5b063d271267b6414cd129
# good: [32d79e68186ae2d123ec2f100c40440fe2951c7e] * ld-elf/linkoncerdiff.d: Don't run for hppa64-hpux. * ld-elf/pr11304a.s: Always have whitespace before directives. * ld-elf/pr11304b.s: Likewise. * ld-selective/selective.exp: Test m68hc1* variant of m6811, m6812. * lib/ld-lib.exp: Likewise, and vice versa.
git bisect good 32d79e68186ae2d123ec2f100c40440fe2951c7e
# bad: [1b7c1b10aaa8bd6eec6555ac64fd070c43a45706] 2012-03-06 Pedro Alves <palves@redhat.com>
git bisect bad 1b7c1b10aaa8bd6eec6555ac64fd070c43a45706
# good: [644cebc98ce121ef7e6a8c0d1867ae01e936b41b] 2012-02-27 Pedro Alves <palves@redhat.com>
git bisect good 644cebc98ce121ef7e6a8c0d1867ae01e936b41b
# bad: [263689d88a2cbcedb42e925400e88f71ddb81698] Fix typo in frame.h:read_frame_register_unsigned function description.
git bisect bad 263689d88a2cbcedb42e925400e88f71ddb81698
# good: [8ba85d852669213fb96aca1cc5449d3789c315e2] Import gnulib's latest update-copyright script...
git bisect good 8ba85d852669213fb96aca1cc5449d3789c315e2
# good: [ad5f7d6ef7055f46c1734b9862bd156c355a8b3d] 2012-03-01 Pedro Alves <palves@redhat.com>
git bisect good ad5f7d6ef7055f46c1734b9862bd156c355a8b3d
# good: [9340a6c0be7b3c4ed008c16c42a9da1350b42c10] 2012-03-01 Pedro Alves <palves@redhat.com>
git bisect good 9340a6c0be7b3c4ed008c16c42a9da1350b42c10
# good: [70221824e31ba9c4e8cc710f11c986c37c947310] 2012-03-01 Pedro Alves <palves@redhat.com>
git bisect good 70221824e31ba9c4e8cc710f11c986c37c947310
# good: [f3b4f45c3398591eed0bf54bb2a51266aa8a2c4a] 2012-03-01 Pedro Alves <palves@redhat.com>
git bisect good f3b4f45c3398591eed0bf54bb2a51266aa8a2c4a
# bad: [a385295e2c80123b85dab47754e049e418925484] * mips-tdep.c (mips32_bc1_pc): New function. (mips32_next_pc): Handle BC1ANY2F, BC1ANY2T, BC1ANY4F, BC1ANY4T, BPOSGE32 and BPOSGE64 instructions. (deal_with_atomic_sequence): Likewise. (mips32_instruction_has_delay_slot): Likewise.
git bisect bad a385295e2c80123b85dab47754e049e418925484
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-14 9:39 ` Orgad Shaneh
@ 2016-04-14 9:47 ` Pedro Alves
0 siblings, 0 replies; 16+ messages in thread
From: Pedro Alves @ 2016-04-14 9:47 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: Luis Machado, gdb-patches, Maciej W. Rozycki
On 04/14/2016 10:39 AM, Orgad Shaneh wrote:
> On Thu, Apr 14, 2016 at 12:22 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 04/14/2016 10:06 AM, Orgad Shaneh wrote:
>>
>>> Ok, autoconf helped. FSF gdbserver 6.5 has the same issue when the gdb
>>> client is >=7.5: "Remote 'g' packet reply is too long".
>>>
>>> So this doesn't seem to be related to Cavium patches.
>>
>> Since you can build gdb now, you should be able to use "git bisect"
>> to find the culprit.
>>
>> Thanks,
>> Pedro Alves
>>
>
> Good point. The first bad commit is 1faeff08.
>
Thanks. That's:
Author: Maciej W. Rozycki <macro@linux-mips.org>
AuthorDate: Thu Mar 1 22:19:48 2012 +0000
...
* mips-tdep.c (mips_generic_reg_names): Remove trailing null
strings.
(mips_tx39_reg_names): Likewise.
(mips_linux_reg_names): New array of register names for Linux
targets.
(mips_register_name): Check for a null pointer in
mips_processor_reg_names and return an empty string.
(mips_register_type): Exclude embedded registers for the IRIX
and Linux ABIs.
(mips_pseudo_register_type): Likewise. Use dynamic numbers to
refer to FP registers, LO, HI, BadVAddr, Cause and PC. Handle
DSP registers.
(mips_stab_reg_to_regnum): Handle DSP accumulators.
(mips_dwarf_dwarf2_ecoff_reg_to_regnum): Likewise.
(mips_gdbarch_init): Likewise. Initialize internal register
indices for the Linux ABI. Use dynamic numbers to refer to
registers, as applicable, while parsing the target description.
Maciej, see https://sourceware.org/ml/gdb-patches/2016-04/msg00310.html .
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message
2016-04-13 21:57 ` Pedro Alves
2016-04-14 8:33 ` Orgad Shaneh
@ 2016-04-14 21:21 ` Maciej W. Rozycki
1 sibling, 0 replies; 16+ messages in thread
From: Maciej W. Rozycki @ 2016-04-14 21:21 UTC (permalink / raw)
To: Pedro Alves; +Cc: Orgad Shaneh, Luis Machado, gdb-patches
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-04-14 21:21 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-10 14:49 PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox