From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1136 invoked by alias); 8 Jan 2018 09:55:30 -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 1126 invoked by uid 89); 8 Jan 2018 09:55:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=standing, Therefore, consequently, sessions X-HELO: 9pmail.ess.barracuda.com Received: from 9pmail.ess.barracuda.com (HELO 9pmail.ess.barracuda.com) (64.235.150.225) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jan 2018 09:55:28 +0000 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx27.ess.sfj.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Jan 2018 09:55:02 +0000 Received: from [10.20.78.204] (10.20.78.204) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Mon, 8 Jan 2018 01:54:55 -0800 Date: Mon, 08 Jan 2018 09:55:00 -0000 From: "Maciej W. Rozycki" To: Joel Brobecker CC: , Pedro Alves , "Maciej W. Rozycki" , , Subject: Re: GDB 8.1 release -- 2018-01-08 update In-Reply-To: <20180108074937.fq44jr4qkdphgeew@adacore.com> Message-ID: References: <20180108074937.fq44jr4qkdphgeew@adacore.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-BESS-ID: 1515405302-637137-12091-684183-3 X-BESS-VER: 2017.16-r1712230000 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.188759 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status:1 X-SW-Source: 2018-01/txt/msg00159.txt.bz2 Hi Joel, > * [Maciej] remote/22597 > Empty `qsThreadInfo' reply handling regression causing inability to execute > > I'm trying to understand whether this is specific to mips or more > general. And whether this only affects GDB when debugging with older > stubs or whether it affects us more generally. > > Depending on the answer, the issue might not be so severe as > to hold the release. > > Maciej - can you tell where we are on this issue, and whether > you think it really is blocking for 8.1? GDB uses the special thread ID 0, standing for `any', which older `gdbserver' versions do not recognise. It does not verify beforehand whether `gdbserver' supports this request and does not handle an error reply gracefully. Consequently an error reply to a `Hg0' packet issued causes GDB to lose track of what is going on, making it impossible to continue with the debug session. This happens with all sessions in the initial connection handshake, making the combination of new GDB and old `gdbserver' unusable. Additionally a `Hg' packet with a legitimate thread ID (the only one at this point) is issued, which is handled correctly and returns a successful reply, immediately before the offending `Hg0' packet with no actions in between. Which means the `Hg0' packet is not really needed as it wouldn't do anything anyway if `gdbserver' supported it. Previously no `Hg' packets were issued at this point in the initial connection handshake; GDB was satisfied with the single thread ID returned by `ThreadInfo' packet queries initially issued and didn't try at this point to switch to the same thread either named explicitly or with the special `any' thread ID, and debugging worked just fine. I can see in the remote log however that an error reply returned in response to `Hg0' issued earlier on is handled gracefully as is for `Hc-1' issued elsewhere, so this is specific to the point and sequence shown in the bug report, and likely the issuing place that is not prepared. I can share the full good and bad log I have if that might help. I have no low-level understanding as to how the offending commit actually caused this change in behaviour, so I cannot comment on it. I think we should avoid introducing functional regressions and continue supporting older stubs, which people may (have to) use for one reason or another. Therefore I think it would be preferable if we fixed the regression before 8.1. Does it answer your question? Maciej