Re: Better MI memory commands

[Eli Zaretskii <eliz at gnu dot org>]

> 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?