* 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