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

[Pedro Alves <palves@redhat.com>]

On 12/12/2017 09:33 PM, Maciej W. Rozycki wrote:
> 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)

So IIUC, the difference is that after this patch, we now start sending those
two Hg / select-thread packets, and I assume that the second one throws,
an error (given the E01) which leaves the thread state out of sync.
Strange, off hand I'm not seeing how this patch can affect/cause this, since
it's mostly touching gdbarch / register bits.

OK, in the bugzilla report you mentioned 
"Empty `qsThreadInfo' reply handling regression causing inability
to execute".

That sequence:

> Sending packet: $qfThreadInfo#bb...Ack
> Packet received: m1814
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: l

looks OK to me off hand, since "l" means there are no more
threads (other than 1814).

Just to double-check; you're positive that this is the right
commit to blame?  I'm wondering that because the remote.c thread
listing bits were touched by other patches recently, and
I'd suspect those changes first.

> 
> 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
> [...]

So here we didn't used to see any Hg.

> 
> 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.
> 

Note: with current master, you can disable XML support with 
"set remote target-features-packet off" before connecting.
Up until recently (7cc244debb58) that command didn't really work.
So maybe it's possible to use current master gdbserver
as proxy for emulating the old gdbserver.

>  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.

Thanks,
Pedro Alves