From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26436 invoked by alias); 9 Feb 2015 18:48:58 -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 26425 invoked by uid 89); 9 Feb 2015 18:48:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 09 Feb 2015 18:48:56 +0000 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t19ImsW6029689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Feb 2015 13:48:54 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t19ImsW6029689 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t19ImsW6029689 Received: from mailsyshubprd08.lss.emc.com (mailhub.lss.emc.com [10.253.24.64]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Mon, 9 Feb 2015 13:47:24 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd08.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t19ImdaK000519 for ; Mon, 9 Feb 2015 13:48:39 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id B11A65DE436; Mon, 9 Feb 2015 13:48:38 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id AE1715D6239 for ; Mon, 9 Feb 2015 13:48:38 -0500 (EST) From: David Taylor To: gdb@sourceware.org Subject: responses to remote target errors Date: Mon, 09 Feb 2015 18:48:00 -0000 Message-ID: <14201.1423507718@usendtaylorx2l> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd54.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00018.txt.bz2 Examining GDB's handling of responses to errors on a remote target, I see that E<2 hex digits> is always accepted as an error return; and that E. appears to sometimes be accepted. Now, how E<2 hex digits> is handled depends upon whether the first hex digit is a 1 or not, if it is a 1, then the second hex digit indicates which field the remote target objected to. But, if the user does not have remote debugging turned on, they probably don't know which low level command caused the problem never mind what was sent in that field to the remote target. If the first hex digit is not a 1, then the error code is thrown away and never seen by the user. The user only knows that there was an error and which user GDB command was the last command issued. I would like E. or some variant of it to be accepted whenever E<2 hex digits> is accepted. And for the string to be printed! One question is whether there should be some `structure' within the string. Possibilities include 2 hex digits followed by a space at the beginning: E.<2 hex digits> or maybe: E.[<2 hex digits> ] I lean towards E. (i.e., no hex digits -- keep it simple), but I could envision the hex digits being used by a GUI. Do others think that this would be a good idea? And, if yes, what form should it take? Thoughts? David -- David Taylor dtaylor at emc dot com