Re: [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors

["Maciej W. Rozycki" <macro@mips.com>]

On Mon, 2 Oct 2017, Pedro Alves wrote:

> When debugging two inferiors (or more) against gdbserver, and the
> inferiors have different architectures, such as e.g., on x86_64
> GNU/Linux and one inferior is 64-bit while the other is 32-bit, then
> GDB can get confused with the different architectures in a couple
> spots.

 Another regression.  This makes `mips-mti-linux-gnu' GDB stop working 
with older stubs.  I have discovered it in an attempt to regression-test 
said GDB with a remote n64 target and `x86_64-pc-linux-gnu' host, and an 
outstanding change which affects non-XML stubs.  Any attempt to continue 
execution after the initial connection fails with:

[...]
Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670
Listening on port 2346
target remote [...]:2346
Remote debugging using [...]:2346
Reading symbols from .../lib64/ld.so.1...done.
[Switching to Thread <main>]
(gdb) continue
Cannot execute this command without a live selected thread.
(gdb) 

This is as from commit 5cd63fda035d.  Up to 5cd63fda035d^ instead I get:

[...]
Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 30044
Listening on port 2346
target remote [...]:2346
Remote debugging using [...]:2346
Reading symbols from .../lib64/ld.so.1...done.
0x000000fff79534f0 in __start () from .../lib64/ld.so.1
(gdb) continue
Continuing.
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main () at .../gdb/testsuite/gdb.base/advance.c:41
41	  c = 5;
(gdb) 

At the protocol level the difference starts here (bad):

Sending packet: $qfThreadInfo#bb...Ack
Packet received: m1814
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
[Switching to Thread <main>]
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:6e70746c5f76657273696f6e
Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Ack
Packet received: OK
Sending packet: $Hg1814#7d...Ack
Packet received: OK
Sending packet: $Hg0#df...Ack
Packet received: E01
(gdb) continue
Cannot execute this command without a live selected thread.
(gdb)

vs (good):

Sending packet: $qfThreadInfo#bb...Ack
Packet received: m154d
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
Sending packet: $mfff726c4f0,4#cb...Ack
Packet received: 03e0c825
Sending packet: $mfff726c4ec,4#fd...Ack
Packet received: 00000000
Sending packet: $mfff726c4f0,4#cb...Ack
Packet received: 03e0c825
0x000000fff726c4f0 in __start () from .../lib64/ld.so.1
Sending packet: $qSymbol::#5b...Ack
Packet received: qSymbol:6e70746c5f76657273696f6e
Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Ack
Packet received: OK
(gdb) continue
Continuing.
Sending packet: $mfff726c4f0,4#cb...Ack
Packet received: 03e0c825
Sending packet: $Z0,120000d6c,4#36...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
[...]

The version of `gdbserver' causing this regression is as at commit 
f8b73d13b7ca^, the last MIPS backend version with no XML support.  It's 
likely that later versions hit this regression too, as the mode of failure 
is clearly not XML-related.

 I'll paste it into Bugzilla too; please feel free to tweak as required, 
and, as always, I'll be happy to supply any details missing.

  Maciej