From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23592 invoked by alias); 23 Jan 2015 17:47:55 -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 23565 invoked by uid 89); 23 Jan 2015 17:47:50 -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 17:47:46 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1YEiKd-0001fq-0h from Sandra_Loosemore@mentor.com for gdb@sourceware.org; Fri, 23 Jan 2015 09:47:43 -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 09:47:42 -0800 Message-ID: <54C2893B.5000900@codesourcery.com> Date: Fri, 23 Jan 2015 18:07: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: CC: Luis Machado Subject: how to fix internal errors on connection to remote stub? Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg00068.txt.bz2 We have a GDB stub we use to interface to various hardware probes. In GDB we normally run programs on the target using a series of commands like (gdb) target remote .... (gdb) load (gdb) c This works about 99.9% of the time. The other .1%, we get "a problem internal to GDB has been detected" from the "target remote" command, because it is trying to ask the target for a backtrace *before* it has loaded the program. At that point, the contents of memory and registers on the target have 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 screws up automated testing. Luis and I have been discussing this and we both think the most likely solution 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 sending now, and have GDB recognize it and at least suppress the initial backtrace, and perhaps also sets a flag disallowing other commands to view target 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? Alternatively, maybe we could have a separate GDB command that can be issued before the "target remote" to suppress the auto-backtrace? 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 having to carry a patch locally. -Sandra