From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17244 invoked by alias); 23 Jan 2015 19:37:24 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 17217 invoked by uid 89); 23 Jan 2015 19:37:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jan 2015 19:37:11 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1YEk2V-0001T3-UQ from Sandra_Loosemore@mentor.com ; Fri, 23 Jan 2015 11:37:07 -0800 Received: from [IPv6:::1] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Fri, 23 Jan 2015 11:37:07 -0800 Message-ID: <54C2A2DF.1050005@codesourcery.com> Date: Sun, 25 Jan 2015 05:54:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Koning CC: "gdb@sourceware.org" , Luis Machado Subject: Re: how to fix internal errors on connection to remote stub? References: <54C2893B.5000900@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2015-01/txt/msg00070.txt.bz2 On 01/23/2015 11:07 AM, Paul Koning wrote: > > If gdbserver is sending something that confuses gdb, the default > answer is that this is a gdb bug (it should not fall over) and > possibly in addition a gdbserver bug (it should obey the protocol > spec). The reason I say “default answer” is because of the standard > distributed systems rule that it’s always your bug if a received > packet causes you to malfunction; the fact that the packet was > invalid is not an excuse. > > You said that the stub is in an “inconsistent state”. I’m not sure > about that. The target is stopped by the initial connection, and at > that point you have a target thread, it’s stopped, it has registers, > so it’s in some state that can be reported. Yes, that state has no > connection to the program GDB knows about, because it’s not in the > target yet. So the target might be in some boot loader or other bit > of skeleton code, but it’s obviously executing something. So I don’t > think “inconsistent” applies from the gdbserver point of view. Hmmm, I'm not so sure about this. In the situations where we have been hitting this problem, a more exact description of what is going on in the stub is this: it previously completed normal execution of some other program in a different gdb instance and sent a 'W' packet. When a new gdb instance reconnects to the stub, the target is still sitting stopped at the semihosting breakpoint that triggered the 'W' packet. That's why I'm wondering whether the response it should be giving to the initial '?' packet on the new connection should be 'W' ("the program has exited and has no meaningful state any more") instead of 'S' ("the program is stopped"). But GDB only accepts a 'W' reply to '?' in extended-remote mode, which isn't supported by this stub. > Instead, it seems that gdb, when it queries gdbserver for the stopped > inferior state, gets back stuff that doesn’t fit in the program it’s > been told about. But so what? That can happen in other places for > other reasons, and gdb usually handles that just fine. Consider the > “heuristic fencepost” machinery that protects from wild backtraces. > So it seems that we just have some gaps in gdb’s robustness, and > those are bugs that should be fixed. > > New commands or new protocol mechanisms don’t seem like the right > answer; it’s not the user’s job to work around gdb bugs, nor is it > gdbserver’s job to know that it is out of sync with gdb. It does seem like GDB could do a better job here of checking that the code in target memory (e.g., the instruction at the reported PC) matches what's expected from the program it's trying to debug. While fixing that might make these errors less likely, it wouldn't be as foolproof as the stub simply telling GDB that it definitely has no useful program state to report yet. -Sandra