From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70066 invoked by alias); 23 Nov 2016 20:40:56 -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 70027 invoked by uid 89); 23 Nov 2016 20:40:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*F:D*be, H*RU:sk:62.89-1, Hx-spam-relays-external:sk:62.89-1, formally X-HELO: mailsec105.isp.belgacom.be Received: from mailsec105.isp.belgacom.be (HELO mailsec105.isp.belgacom.be) (195.238.20.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Nov 2016 20:40:45 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2B8AgCY/TVY/z5ZslteGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR+EVYpFlxomAZI+gg6CB4YhAoIcQBQBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEEIzMjEAgDDgoCAiYCAjkeBokErjmCKYtcAQEIAiWBC4UzhFuHTYJdBZpPg?= =?us-ascii?q?XaPCpAxSY0hhAweN4ZdPYh5AQEB?= Received: from 62.89-178-91.adsl-dyn.isp.belgacom.be (HELO md) ([91.178.89.62]) by relay.skynet.be with ESMTP/TLS/AES128-GCM-SHA256; 23 Nov 2016 21:40:40 +0100 Message-ID: <1479933767.1447.27.camel@skynet.be> Subject: Re: [PATCH] gdbserver: Introduce write_error_msg From: Philippe Waroquiers To: Pedro Alves Cc: gdb-patches@sourceware.org Date: Wed, 23 Nov 2016 20:40:00 -0000 In-Reply-To: <1479915352-23983-1-git-send-email-palves@redhat.com> References: <1479915352-23983-1-git-send-email-palves@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00686.txt.bz2 On Wed, 2016-11-23 at 15:35 +0000, Pedro Alves wrote: > Instead of writing an error message to (gdbserver's) stderr and then > returning back "E01" to GDB, send the error message to GDB directly > using the E.MSG format, so the user can potentially see it. Several > places in the code already do this manually. This patch adds a new > function (write_error_msg) that abstracts out the "E." prefix detail. The protocol description/doc does not (very) clearly describe E. prefix. In the doc, I found the E. is used only at a few places: vFlashWrite and a few packets used for branch tracing, while the gdbserver code uses it at more places. I think that gdb will accept such an error reply as a reply to any? many? packet that can cause an error (at least I have used E. here and there in Valgrind gdbserver and it is always accepted by gdb). The E (error packet) is not formally described. In the protocol Overview, there is: " The error response returned for some packets includes a two character error number. That number is not well defined." But the E packet itself seems not well defined :). This patch is maybe the occasion to clarify/document explicitely what gdbserver stubs are allowed to send as an error response, and then change the doc to just indicate what packets can send an E error message, rather than document that 'E NN' is only to be expected for many packets. Thanks Philippe