public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Pedro Alves <palves@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] Document "E.MESSAGE" RSP errors Date: Fri, 26 Apr 2024 20:23:49 +0000 (GMT) [thread overview] Message-ID: <20240426202349.E6DBE3858431@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d0273077ccbf6847b448604d407d41af3f987652 commit d0273077ccbf6847b448604d407d41af3f987652 Author: Pedro Alves <pedro@palves.net> Date: Thu Apr 18 20:22:36 2024 +0100 Document "E.MESSAGE" RSP errors For many years, GDB has accepted a "E.MESSAGE" error reponse, in addition to "E NN". For many packets, GDB strips the "E." before giving the error message to the user. For others, GDB does not strip the "E.", but still understands that it is an error, as it starts with "E", and either prints the whole string, or ignores it and just mentions an error occured (same as for "E NN"). This has been the case for as long as I remember. Now that I check, I see that it's been there since 2006 (commit a76d924dffcb, also here: https://sourceware.org/pipermail/gdb-patches/2006-September/047286.html). All along, I actually thought it was documented. Turns out it wasn't. This commit documents it, in the new "Standard Replies" section, near where we document "E NN". The original version of this 3-patch documentation series was a single CodeSourcery patch that documented the textual error as "E.NAME.MESSAGE", with MESSAGE being 8-bit binary encoded. But I think the ship has sailed for that. GDBserver has been sending error messages with more than one "." for a long while, and with no binary encoding. Still, I've preserved the "Co-Authored-By" list of the original larger patch. The 'qRcmd' and 'm' commands are exceptions and do not accept this reply format. The top of the "Standard Replies" section already says: "All commands support these, except as noted in the individual command descriptions." So this adds a note to the description of 'qRcmd' and 'm', explicitly stating that they do not support this error reply format. Change-Id: Ie4fee3d00d82ede39e439bf162e8cb7485532fd8 Co-Authored-By: Jim Blandy <jimb@codesourcery.com> Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com> Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com> Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com> Approved-By: Eli Zaretskii <eliz@gnu.org> Diff: --- gdb/doc/gdb.texinfo | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index b5f6b9cd802..92731c510b2 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -42559,6 +42559,11 @@ number. In almost all cases, the protocol does not specify the meaning of the error numbers; @value{GDBN} usually ignores the numbers, or displays them to the user without further interpretation. +@anchor{textual error reply} +@item @samp{E.@var{errtext}} +An error has occurred; @var{errtext} is the textual error message, +encoded in @sc{ascii}. + @end table @node Packets @@ -42885,6 +42890,10 @@ The reply may contain fewer addressable memory units than requested if the server was able to read only part of the region of memory. @end table +Unlike most packets, this packet does not support +@samp{E.@var{errtext}}-style textual error replies (@pxref{textual +error reply}). + @item M @var{addr},@var{length}:@var{XX@dots{}} @cindex @samp{M} packet Write @var{length} addressable memory units starting at address @var{addr} @@ -44391,6 +44400,10 @@ A command response with no output. A command response with the hex encoded output string @var{OUTPUT}. @end table +Unlike most packets, this packet does not support +@samp{E.@var{errtext}}-style textual error replies (@pxref{textual +error reply}). + (Note that the @code{qRcmd} packet's name is separated from the command by a @samp{,}, not a @samp{:}, contrary to the naming conventions above. Please don't use this packet as a model for new @@ -45447,8 +45460,6 @@ Reply: @table @samp @item OK Branch tracing has been enabled. -@item E.errtext -A badly formed request or an error was encountered. @end table @item Qbtrace:pt @@ -45458,8 +45469,6 @@ Reply: @table @samp @item OK Branch tracing has been enabled. -@item E.errtext -A badly formed request or an error was encountered. @end table @item Qbtrace:off @@ -45469,8 +45478,6 @@ Reply: @table @samp @item OK Branch tracing has been disabled. -@item E.errtext -A badly formed request or an error was encountered. @end table @item Qbtrace-conf:bts:size=@var{value} @@ -45481,8 +45488,6 @@ Reply: @table @samp @item OK The ring buffer size has been set. -@item E.errtext -A badly formed request or an error was encountered. @end table @item Qbtrace-conf:pt:size=@var{value} @@ -45493,8 +45498,6 @@ Reply: @table @samp @item OK The ring buffer size has been set. -@item E.errtext -A badly formed request or an error was encountered. @end table @end table
reply other threads:[~2024-04-26 20:23 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240426202349.E6DBE3858431@sourceware.org \ --to=palves@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).