From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9207 invoked by alias); 23 Jan 2015 18:07:57 -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 9152 invoked by uid 89); 23 Jan 2015 18:07:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: resqmta-po-12v.sys.comcast.net Received: from resqmta-po-12v.sys.comcast.net (HELO resqmta-po-12v.sys.comcast.net) (96.114.154.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 23 Jan 2015 18:07:47 +0000 Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-12v.sys.comcast.net with comcast id jW6l1p0054tLnxL01W7kJv; Fri, 23 Jan 2015 18:07:44 +0000 Received: from akdesign.dyndns.org ([50.169.224.229]) by resomta-po-02v.sys.comcast.net with comcast id jW7j1p00X4xb7Ai01W7kV6; Fri, 23 Jan 2015 18:07:44 +0000 Received: from pkoning.akdesign.com (pkoning.akdesign.com [192.168.10.125]) by akdesign.dyndns.org (Postfix) with ESMTP id 8F5993C07AC; Fri, 23 Jan 2015 13:07:43 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: how to fix internal errors on connection to remote stub? From: Paul Koning In-Reply-To: <54C2893B.5000900@codesourcery.com> Date: Fri, 23 Jan 2015 19:37:00 -0000 Cc: "gdb@sourceware.org" , Luis Machado Content-Transfer-Encoding: quoted-printable Message-Id: References: <54C2893B.5000900@codesourcery.com> To: Sandra Loosemore X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00069.txt.bz2 > On Jan 23, 2015, at 12:47 PM, Sandra Loosemore = wrote: >=20 > We have a GDB stub we use to interface to various hardware probes. In GD= B we normally run programs on the target using a series of commands like >=20 > (gdb) target remote .... > (gdb) load > (gdb) c >=20 > This works about 99.9% of the time. The other .1%, we get "a problem int= ernal to GDB has been detected" from the "target remote" command, because i= t is trying to ask the target for a backtrace *before* it has loaded the pr= ogram. At that point, the contents of memory and registers on the target h= ave no relation to the program gdb is trying to debug, and GDB gets mighty = confused. Maybe this isn't so awful for manual use, but it certainly screw= s up automated testing. >=20 > Luis and I have been discussing this and we both think the most likely so= lution is for the stub to answer the initial '?' packet with some response = that indicates it's in an inconsistent state, rather than the "S00" it is s= ending now, and have GDB recognize it and at least suppress the initial bac= ktrace, and perhaps also sets a flag disallowing other commands to view tar= get state (variable values, etc) until it's cleared by the "load" command. = Maybe the 'W' stop reply could be used for this purpose, or maybe we need = to introduce a new one? >=20 > Alternatively, maybe we could have a separate GDB command that can be iss= ued before the "target remote" to suppress the auto-backtrace? >=20 > Any other ideas? What do other folks think is the right solution? We'd = much rather fix this in a way that's acceptable for mainline rather than ha= ving to carry a patch locally. 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 =93de= fault answer=94 is because of the standard distributed systems rule that it= =92s always your bug if a received packet causes you to malfunction; the fa= ct that the packet was invalid is not an excuse. You said that the stub is in an =93inconsistent state=94. I=92m not sure a= bout that. The target is stopped by the initial connection, and at that po= int you have a target thread, it=92s stopped, it has registers, so it=92s i= n some state that can be reported. Yes, that state has no connection to th= e program GDB knows about, because it=92s not in the target yet. So the ta= rget might be in some boot loader or other bit of skeleton code, but it=92s= obviously executing something. So I don=92t think =93inconsistent=94 appl= ies from the gdbserver point of view.=20=20 Instead, it seems that gdb, when it queries gdbserver for the stopped infer= ior state, gets back stuff that doesn=92t fit in the program it=92s been to= ld about. But so what? That can happen in other places for other reasons,= and gdb usually handles that just fine. Consider the =93heuristic fencep= ost=94 machinery that protects from wild backtraces. So it seems that we j= ust have some gaps in gdb=92s robustness, and those are bugs that should be= fixed.=20=20 New commands or new protocol mechanisms don=92t seem like the right answer;= it=92s not the user=92s job to work around gdb bugs, nor is it gdbserver= =92s job to know that it is out of sync with gdb. paul