From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70567 invoked by alias); 13 Dec 2017 00:45:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 70549 invoked by uid 89); 13 Dec 2017 00:45:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Dec 2017 00:45:46 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCB1685540; Wed, 13 Dec 2017 00:45:45 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 68489600CA; Wed, 13 Dec 2017 00:45:43 +0000 (UTC) Subject: Re: [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors To: "Maciej W. Rozycki" References: <1506957311-30028-1-git-send-email-palves@redhat.com> <1506957311-30028-4-git-send-email-palves@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <7c49740a-3b0b-8628-3f98-4f373f24ef7f@redhat.com> Date: Wed, 13 Dec 2017 00:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-12/txt/msg00287.txt.bz2 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
] > (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
] > 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