From: Eli Zaretskii <eliz@gnu.org>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Better MI memory commands
Date: Wed, 11 Aug 2010 18:00:00 -0000 [thread overview]
Message-ID: <83fwyluj0q.fsf@gnu.org> (raw)
In-Reply-To: <201008111637.49621.vladimir@codesourcery.com>
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 11 Aug 2010 16:37:49 +0400
> Cc: gdb-patches@sources.redhat.com
>
> > > +The output of the command has a result record named @samp{memory},
> > ^^^^^^^^^^^^^^^^^^^
> > Perhaps "is a result record"?
>
> Nope. "result record" is actually a nonterminal in MI grammar, and output
> of a command may have result records but is never a result record itself.
>
> > And what is the importance of naming
> > this record `memory'? why is the name important here?
>
> Because for frontend to access a result record in a command output, it
> has to know its name.
Then perhaps
The result record (@pxref{GDB/MI Result Records}) that is output of
the command includes a field named @samp{memory} whose content is a
list of tuples ...
> > > +@item contents
> > > +The contents of the memory block, as hex-encoded string of bytes.
> >
> > But your example shows this:
> >
> > > + contents="01000000020000000300"@}]
> >
> > This doesn't look like a ``string of bytes'' to me. Or maybe I don't
> > understand what you meant by that?
>
> It seems very much like a hex-encoded string of bytes. Maybe, "hex-encoded
> sequence of bytes" will work better?
I suggest just
The contents of the memory block, in hex.
> > > +@item @var{contents}
> > > +The hex-encoded bytes to write. The size of this parameter determines
> > > +how many bytes should be written.^^^^^^^^
> >
> > You probably meant "the value", not "the size".
>
> Actually, "the size". A parameter is a string, a string has a size
A string has a length, not size, so please use that. Actually,
perhaps this sentence should be simply removed, as it seems to say
something trivial, doesn't it?
> What about the attached revision?
Okay, with the above changes and two more comments:
> +This command attempts to read all accessible memory regions in the
> +specified range. First, all regions marked as unreadable in the memory
> +map (if one is defined) will be skipped.
^^^^^^^^^^^^^^^^^^^^^^^
I asked for a cross-reference here to where memory maps are
described.
> +At present, if multiple
What happened here?
next prev parent reply other threads:[~2010-08-11 18:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 8:33 Vladimir Prus
2010-06-25 16:05 ` Eli Zaretskii
2010-08-11 12:38 ` Vladimir Prus
2010-08-11 18:00 ` Eli Zaretskii [this message]
2010-08-12 7:25 ` Vladimir Prus
2010-08-12 17:04 ` Eli Zaretskii
2010-08-13 13:23 ` Vladimir Prus
2010-07-07 16:30 ` Daniel Jacobowitz
2010-07-09 18:54 ` Vladimir Prus
2010-07-09 18:59 ` Daniel Jacobowitz
2010-08-11 12:38 ` Vladimir Prus
2010-08-11 21:10 ` Daniel Jacobowitz
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=83fwyluj0q.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@codesourcery.com \
/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