Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: gdb@sourceware.org
Subject: Re: RFC: Add named errors and messages to remote protocol
Date: Wed, 04 Jul 2007 07:08:00 -0000	[thread overview]
Message-ID: <m3lkdwejdz.fsf@codesourcery.com> (raw)
In-Reply-To: <20070703171613.GH2868@caradoc.them.org> (Daniel Jacobowitz's message of "Tue, 3 Jul 2007 13:16:13 -0400")


Daniel Jacobowitz <drow@false.org> writes:
> On Mon, Jun 18, 2007 at 05:11:16PM -0700, Jim Blandy wrote:
>> 
>> Here's a patch we've just started using internally at CodeSourcery
>> which implements something that's been discussed on and off for years:
>> extending the remote protocol to support named errors, and to provide
>> error messages along with errors.
>> 
>> This is a pretty rough patch.  Probably all the sites in remote.c that
>> check for errors should call error_from_remote.  But hopefully the
>> basic idea is clear enough to critique.
>
> This is a remote protocol change; I believe the custom is to post just
> the documentation or a description on gdb@ first in case anyone has
> comments.

Okay.  Here's the new node to be added to the remote protocol section
of the manual.  It goes before the packet descriptions, which are then
simplified by removing the descriptions of the standard replies.  The
description of the notation we use to describe packet formats also
gets moved above this.


@node Standard Replies
@section Standard Replies

The remote protocol specifies a few standard replies.  All commands
support these, except as noted in the individual command descriptions.

@table @samp

@item
@cindex empty response, for unsupported packets
@cindex unsupported packets, empty response for
For any @var{command} not supported by the stub, an empty response
(@samp{$#00}) should be returned.  That way it is possible to extend the
protocol.  A newer @value{GDBN} can tell if a packet is supported based
on that response.

A stub is required to support the @samp{g}, @samp{G}, @samp{m}, @samp{M},
@samp{c}, and @samp{s} @var{command}s.  All other @var{command}s are
optional.
on that response (but see also @ref{qSupported}).

@item E @var{xx}
An error has occurred; @var{xx} is a two-digit hexadecimal error
number.  In almost all cases, the protocol does not specify the
meaning of the error numbers; GDB usually ignores the numbers, or
displays them to the user without further interpretation.

@item E.@var{name}@r{[}.@var{message}@r{]}
An error has occurred; @var{name} is the name of the error.  The name
may contain letters, numbers, and @samp{-} characters.  If present,
@var{message} is an error message, encoded using the escaped eight-bit
conventions for binary data described above.

Except as noted, named errors may only be returned to commands
documented to expect them; this ensures that older stubs can interact
with newer versions of @value{GDBN}, even when interpretations for
named errors have been added to the protocol.

The protocol uses the following error names:

@table @samp

@item fatal
A fatal error has occurred; the stub will be unable to interact
further with @value{GDBN}.  Fatal errors should always include a
message explaining their cause.

Any command may return this error.

@item memtype
The memory addressed is of the wrong type for the given command.  For
example, a @samp{vFlashWrite} command applied to non-flash memory
elicits an @samp{E.memtype} error response.

@end table
@end table


       reply	other threads:[~2007-07-04  7:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3fy4oyfa3.fsf@codesourcery.com>
     [not found] ` <20070703171613.GH2868@caradoc.them.org>
2007-07-04  7:08   ` Jim Blandy [this message]
2007-07-04 21:29     ` Eli Zaretskii
2007-07-05 19:39       ` Jim Blandy

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=m3lkdwejdz.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=gdb@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: link
Be 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