This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
- From: Pedro Alves <palves at redhat dot com>
- To: "Maciej W. Rozycki" <macro at mips dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 13 Dec 2017 00:45:42 +0000
- Subject: Re: [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
- Authentication-results: sourceware.org; auth=none
- References: <1506957311-30028-1-git-send-email-palves@redhat.com> <1506957311-30028-4-git-send-email-palves@redhat.com> <alpine.DEB.2.00.1712122103390.4584@tp.orcam.me.uk>
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